Most people assume that importing a managed solution overwrites whatever was there before. It does not. Dataverse keeps every version of every component in a stack, then computes which one you actually see at runtime. That mechanism, Power Platform solution layers, is behind half of the “my update did not show up” tickets I have seen. It is also the thing that quietly decides whether a pro-dev team and a group of citizen devs can work in the same environment without destroying each other’s work.
The Surface Behaviour: The Update That Never Arrives
The classic symptom looks like this. A pro-dev team ships version 2.0 of a managed solution with an updated main form on the Account table. The import completes with zero errors. The pipeline is green. And the form in the target environment still shows the old layout.
The first instinct is to blame caching, then the pipeline, then the solution packager. I burned an afternoon in exactly that rabbit hole before I looked at the layer stack. The real culprit was a maker who had edited that form directly in the target environment three months earlier. That single edit created an unmanaged customization sitting above the managed solution, and it masked every managed update that came afterwards. Version 2.0 landed exactly where it was supposed to. Nobody could see it.
How Power Platform Solution Layers Resolve What You See
Every solution-aware component in Dataverse carries an ordered stack. At the bottom sits the system layer, the out-of-box definition Microsoft ships. Above that sit managed layers, one per managed solution that touches the component, ordered by installation sequence. And on top, always, sits the unmanaged layer, which holds any direct customization made in that environment.
At runtime, Dataverse walks the stack from the top down. For most component types the rule is simple: the topmost layer that defines the component wins entirely. There is no partial blending for a view or a plugin step. Forms and site maps are the notable exceptions, because they merge across layers, which is its own source of surprises.
You can inspect this yourself. In the maker portal, select a component inside a solution and open Solution layers from the command bar. It shows you the full stack and lets you diff what each layer changed. The official documentation on solution layers covers the merge rules per component type, and it is worth reading properly rather than skimming, because the behaviour is not uniform.
The Edge Cases That Cost Real Time
The unmanaged layer never expires. If someone makes a direct edit in production, that layer masks the managed layers below it until someone explicitly removes it with the remove active customizations operation. You can import version 3, version 4, version 5, and nothing visible changes. The imports are not failing. They are landing underneath a mask.
Layer order is install order, not version number and not intent. If two managed solutions both customize the same view, the one installed second sits higher and wins, even if the first one carries the change your team actually cares about. I have watched teams reorder their deployment sequence to fix a display bug without understanding why it worked, which means the fix was luck, not engineering.
Form merging deserves its own warning. Because forms merge across layers instead of replacing wholesale, you can end up with a rendered form that no single team designed. A section from the base solution, a tab from a second solution, a field placement from an unmanaged tweak. It looks like corruption. It is the merge algorithm doing exactly what it is documented to do.
Why This Is the Contract Between Pro Devs and Makers
The reason I care about this mechanism is not ALM purity. It is that the layer stack is the actual contract that lets pro-dev and low/no-code work coexist. Pro devs ship managed solutions through pipelines and source control. Makers build in a dev environment inside their own solution, which deploys as its own managed layer sitting above the pro-dev layer. Both sides can move independently, and the stack keeps the boundaries honest.
That contract holds under exactly one condition: no unmanaged edits in test or production. Every direct tweak in a downstream environment is a silent mask over every future deployment. The trade-off is real, and I will not pretend otherwise. Makers lose the ability to hotfix a label in production in thirty seconds. That feels slow until you have spent a day proving that a green import changed nothing, and then it feels cheap. Before you reach that point, running a Power Platform licensing audit across your environments can surface other hidden mismatches that compound the same class of problem.
I made a similar point about ownership in my post on Dataverse business skills: logic nobody can find is logic nobody can fix. Unmanaged layers in production are the same failure mode wearing a different jacket. In my experience, teams that check the layer stack before blaming the pipeline resolve these tickets in minutes instead of days. The mechanism is not hidden. Most people just never look at it. The same discipline applies when variables behave unexpectedly at scale — as I covered in why variables break when you turn on concurrency in Power Automate, hidden state that looks correct during authoring can silently produce wrong results at runtime for the exact same reason: execution order is not what you assumed.
Frequently Asked Questions
What are Power Platform solution layers?
Power Platform solution layers are an ordered stack that Dataverse maintains for every solution-aware component, starting with Microsoft’s base system layer, followed by managed solution layers, and topped by any unmanaged customizations made directly in the environment. At runtime, Dataverse works down the stack from the top to determine which version of a component is actually displayed or used.
Why does my managed solution update not show up after importing?
A direct customization made in the target environment creates an unmanaged layer that sits above all managed layers and takes priority over them. Even if your managed solution imported successfully, that unmanaged layer masks the changes you shipped, making it appear as though the update never arrived.
How do I see which solution layer is controlling a component in Power Platform?
In the maker portal, select the component inside a solution and choose Solution layers from the command bar. This shows you the full layer stack for that component and lets you compare what each layer has changed.
When should I be concerned about unmanaged customizations in a managed environment?
Any time a maker edits a component directly in an environment that receives managed solutions, an unmanaged layer is created that will permanently override updates shipped through those managed solutions. This is especially important in shared or production environments where pro-dev and citizen dev teams are working alongside each other.
Leave a Reply