Why Layering Causes So Many Problems

Hardly any support case in Dataverse environments is as common as this one. A change was delivered and the import succeeded, but the form looks exactly as before. The cause is almost always the same, and it is not a bug but a feature: the layer model.

How the layers work

Several solutions can define the same component at the same time. Dataverse stacks these definitions. At the bottom is the system layer. Above it sit the managed solutions in the order of their installation. At the very top sits a possible unmanaged layer. What the user sees is always the topmost layer that defines the property in question.

The model is consistent in itself. A partner add-on can customize a Microsoft form, and a customer can customize the partner form once more. The parties do not have to coordinate. If you uninstall a layer, the one below comes back into view.

Why it still causes problems all the time

The problem is not the logic but the invisibility. In daily work, nobody sees the layers. You see a form, not the four definitions behind it.

The classic is the unmanaged layer at the very top. It appears as soon as someone customizes a component directly in the environment. Even with the best intentions, or just for a quick test. From then on, this layer beats every future managed delivery of the component. The fix arrives and stays invisible, buried under the manual change.

The second classic is the order of managed solutions among themselves. Two solutions define the same property. Which one wins depends on the installation order, and that was not necessarily identical in test and production. The result: both environments are correct in themselves, and still different.

Making layers visible

The platform can show the layers. You just need to know where. On every component in the solution view, there is the Solution Layers display. It lists the layer stack for that one object, including a possible unmanaged layer. For troubleshooting a single case, that is fully enough.

For an overview of a whole environment, it is not enough, because nobody clicks through a thousand components. The reverse view helps here. Read from the export of the affected solutions which components are defined in several solutions at once. This overlap list is the map of potential conflicts, and it is usually shorter than feared.

One subtlety makes things even less clear: not all components are overwritten as a whole. Forms and SiteMaps, for example, are partly merged when layered. The visible result then contains elements from several layers at once. If you try to predict the end result in your head, you lose. Looking is the only reliable way.

If you cannot explain a deployment effect, open the layer display of the affected component first. In nine out of ten cases, the answer is there. Besides XML analysis, tools such as the Solution Layers Explorer of the XRM Toolbox can help here. They do, however, need access to your environment.