Understanding Solution Layers and Component Merging

1. The Hierarchy of Customizations: Solution Layers

Every component in a Dataverse environment, like a table, form, or app, can be thought of as a stack of layers. The final behavior of that component is determined by the properties defined in the top-most layer.

There are two fundamental types of layers:

• The Unmanaged Layer: There is only one unmanaged layer in an environment. All ad-hoc customizations you make directly in an environment (often called "active customizations") and all components imported via an unmanaged solution reside in this single layer. This layer always sits at the very top of the stack.
• Managed Layers: Below the unmanaged layer, there can be multiple managed layers. Each managed solution you import creates its own layer. If you import Solution A and then Solution B, the stack will look like this: Solution B (top), Solution A (bottom). This is often called a "Last one in wins" model. At the very bottom of all managed layers is the System layer, which contains the default platform components.

The following article from Microsoft Learn provides the official definition.

This image provides a great visual from the Power Apps interface, showing how you can inspect these layers.

2. Manipulating Layers: Upgrades, Updates, and Patches

The different options you see when importing a solution are, in effect, tools for manipulating these layers. Your extensive experience with deployments will make the strategic implications of these choices immediately apparent.

The following video provides an excellent practical demonstration of how different import choices affect the solution layers and the overall state of the environment.

Let's summarize the behaviors you just saw in the video:

• Upgrade: This is the standard, recommended approach. It replaces the entire old solution layer with the new one. If a component was deleted in the source, it gets deleted in the target. This keeps environments in sync.
• Update: This option merges the new solution with the old one. It adds new components but does not remove components that were deleted in the source. This should generally be avoided as it leads to environment drift.
• Stage for Upgrade: This imports the new version as a temporary _Upgrade layer on top of the old one. The system's behavior is defined by this top layer. However, the old solution is not removed until you explicitly click "Apply Upgrade," which then merges the layers and cleans up the old version. This allows for a controlled cutover.
• Patch: A patch is a small, dependent solution used for minor updates or hotfixes. It creates a new layer on top of its parent solution. Patches are useful because they are lightweight and can be easily uninstalled to revert a specific change.
• Clone Solution: This action merges all existing patches for a solution into a new, single version of the base solution, effectively "flattening" the layers. This unlocks the parent solution for the next cycle of major development.

3. "Top Wins" vs. Merge Behavior

Now that we know how layers are created and stacked, the final question is: how does the system calculate the final behavior of a component? For most components, the rule is simple: Top Wins. Whatever is defined in the top-most layer is what you get at runtime.

However, for a few specific and complex components, Dataverse is smarter. Instead of just taking the top layer, it merges the definitions from different layers together.

As the article states, the components with special merge behavior are:

• Model-driven Apps
• Forms
• Site Maps

Given your background with Dynamics 365, understanding how form customizations are merged is particularly important.

The Form Merge Process

When multiple solution layers modify the same form, the system doesn't just pick one version. It reads the FormXML from each layer and combines them.

• Additive Changes: If Solution A adds Field A to a form section and Solution B adds Field B to the same section, the final form will show both Field A and Field B.
• Conflicts: If changes conflict in a way the system can't resolve, it will create a Conflicts Tab on the form and place the problematic components there. It's then up to a customizer to move these components to their desired location in an unmanaged layer and remove the tab.
• Best Practice: To avoid conflicts, when you are customizing a form from another managed solution, it's best to add your new fields or controls inside new container elements (like a new tab or a new section on an existing tab) rather than adding them directly into a container from the base solution.

Conclusion

You have now completed the solution architecture module. By understanding the principles of managed solutions and the mechanics of solution layering, you have the foundational knowledge for building, deploying, and maintaining robust and governable Power Platform applications.

Key Takeaways:

• Customizations exist in a stack of layers: a single Unmanaged layer at the top, followed by one or more Managed layers.
• For most components, the Top Wins rule applies: the top-most layer defines the component's behavior.
• For Forms, Model-driven Apps, and Site Maps, the platform intelligently merges definitions from multiple layers.
• Solution import options (Upgrade, Update, Patch) are tools for developers to strategically manage these layers during the ALM process. Upgrade is the standard, while Patches are for tactical fixes.

Up Next:
With our ALM foundation firmly in place, we will pivot in the next module to advanced server-side development. Drawing on your deep experience with classic Dynamics 365, we will start by exploring a critical strategic decision in modern plugin development: evaluating synchronous vs. asynchronous plugin execution and selecting the appropriate pipeline stages for different business requirements.