Solution layering (Power Platform)

What is solution layering?

Solution layering is the mechanism Power Platform uses to order several definitions of the same component. The layers decide which configuration is visible and active while people use the app.

Microsoft Dataverse has a system layer, managed layers, and one active unmanaged layer. Within a single managed solution, its base, any patches, and a pending upgrade can also form their own layers.

Layering works per component. One app can have a form with an active layer on top, while another table in the same app uses only its managed base. There is no single layer for the whole environment.

The layer stack

At the bottom is the system layer, which holds the tables and components the platform needs to run. Managed solutions sit above it in the order they were installed, so the last one installed sits above the ones before it and can customise them.

The active unmanaged layer sits above all the managed layers. It holds every direct customisation in the environment, even when makers used different unmanaged solution containers to make them, because all unmanaged changes share this one layer.

Inside a managed solution, the base, any patches, and a pending upgrade form their own order. Selecting Apply upgrade flattens the relevant layers into a new base.

Top wins and merge behaviour

For many components the top layer sets the runtime value. This is top-wins: a column length from a higher layer overrides the value from a lower one.

Model-driven apps, forms, and sitemaps use merge behaviour for some parts instead. Elements from different layers are combined rather than one replacing the other outright. Merging keeps the app working, but it does not guarantee every combination is sensible: conflicting edits can produce a result that is technically valid yet not what anyone intended.

A worked example makes top-wins concrete. Suppose a column starts at 1,024 characters. One managed solution shortens it to 128, a second managed solution widens it to 4,096, and finally a direct unmanaged edit sets it to 65,536. The user experiences 65,536, because the active unmanaged layer is on top. The example also shows why column length is a poor thing to keep changing, since shortening one can truncate stored data.

A form incident

A managed base solution ships a case form. A second managed solution adds a compliance tab. Then an administrator hides a field directly in production.

That last change goes into the active layer, above both managed layers. A later release edits the same field in the base solution, but users still see the production tweak. The See solution layers view in Power Apps shows which solution introduced each property, so the team can fold the wanted change into source control and then remove the active layer.

Update, upgrade, and uninstall

An update lays a new version over an existing managed solution. A staged upgrade adds a temporary pending layer, and Apply upgrade replaces the old base and can delete components that are no longer in the new version.

When a managed solution is removed, the layer below it takes effect again. That return to older behaviour is normal layering, but data and dependencies can block or complicate an uninstall. So do not plan around only what is on top right now. Understand which owner and which dependencies sit under the active definition first.

Diagnosing with solution layers

When a release does not behave as expected, first confirm the right version was imported, then inspect the layers of the component in question. Look for an active customisation, a higher managed extension, a leftover patch, or a pending upgrade. Do not compare only solution versions, because the problem can sit on a single property.

Document the cause before removing any layer. An active layer may be unwanted, but it may also hold an emergency production fix that was never captured anywhere else. Solution layering is not a fault in the platform, it is a composition model, and reliable Power Platform ALM depends on teams knowing which layer owns each critical component.