Solutions and layering

What it does

Every component in Dataverse has a stack of definitions behind it, and what users actually get is whatever sits at the top. Dataverse has two layer levels: a single unmanaged layer above everything, and the managed layers beneath it, with the system layer at the base.

Key facts

The unmanaged layer is one layer, not a stack. All unmanaged solutions and unmanaged customisations live in it, and it always sits above every managed layer.
Managed layers do stack. The last managed solution installed sits above the ones installed before it, so a later solution can customise an earlier one.
When two managed solutions conflict, runtime behaviour is either last-one-wins or a merge, depending on the component type. Forms, sitemap, ribbon and app modules merge; most other things don't.
Uninstall a managed solution and the managed layer below it takes effect. Uninstall all of them and you fall back to the system layer.
See solution layers (Advanced > See solution layers on a component) shows the whole stack in order, most recent at the top, with the active layer determining runtime behaviour.
The Properties pane on a layer has an Updated tab showing only what that layer changed and an All Properties tab showing everything. There are extra tabs for role privileges, choice values and localised labels.
Remove active customizations strips the unmanaged layer for a component. It can't be undone, and data associated with the unmanaged customisation can be lost.
If the unmanaged layer is the only layer for a component — it's the base layer — you can't remove it that way. You have to delete the component.
The Overwrite Customizations import option removes unmanaged customisations on components in the solution, but doesn't affect merge-behaviour components or components with other managed solutions layered on top.

When to use / skip

Layer inspection is a diagnostic tool, not a design tool. You go there when something behaves differently in test than in dev and nobody can explain it — which in practice means an unmanaged customisation someone made directly in the environment is winning over the managed solution you deployed. The design decision that actually matters is not to be in that position: keep test and production free of unmanaged layers, and treat every unmanaged layer you find there as a defect rather than a fact of life. Removing active customisations is the fix, but it's destructive and one-way, so understand what the layer contains before you press it.

Configuration decisions

Solution granularity, because the number of managed layers you create is the number of places a conflict can hide. Fewer, well-scoped solutions beat many overlapping ones.
Install order for managed solutions, since later installs sit higher and can override earlier ones.
Whether to use table segmentation so a solution only carries the assets it actually changed, rather than laying a full table over everything below it.
Whether an import uses Overwrite Customizations, which is a policy decision about whose changes win.
Where a component is created in the first place, since the publisher of that solution owns it.

Gotchas

The unmanaged layer beating everything is the root cause of most "it worked in dev" incidents. Somebody edited a form directly in production, and every subsequent managed deployment silently loses to it.
Removing active customisations can lose data, and there's no undo. Not a command to run on a call while someone waits.
Merge behaviour applies to forms, sitemap, ribbon and app modules and not to other component types, so "last one wins" is only true for part of your solution.
Adding a whole table to a solution when you only changed one column lays an unnecessary layer over everything on that table, and creates dependencies you didn't intend.
Uninstalling a managed solution to "clean up" reveals whatever was underneath, which is frequently not what anyone expected.

Consultant notes

Teach the client's admins to open See solution layers before they raise a ticket. It answers the question faster than you can, and it makes the unmanaged-layer problem visible to the people creating it.
Make "no unmanaged changes in test or production" a written rule with a named exception process. Without one it degrades within a quarter.
Segment tables as a habit. It's the cheapest thing you can do to keep the layer stack readable two years in.
When you inherit an environment, audit the layers on the busiest tables first. That's where the accumulated shortcuts live.

Worth another look if the layering model gains more than the two levels, or if remove-active-customizations ever becomes reversible.