PowercademyPowercademy
For BusinessesSuccess KitBlogM-AI Accelerator
Log inStart for free
For BusinessesSuccess KitBlogM-AI Accelerator
Log inStart for free
All posts

Power Platform Solution Layering 101: How Layers Actually Work

Howdang Rashid

Saturday, 22 August 2026 · 3 min read

Solution layers are the reason a field label can say one thing in your solution and another thing on the live form - and the reason a 'missing' deployment change is usually not missing at all, just buried. Every solution you import and every ad-hoc change you make becomes a layer stacked on top of what was there before, and the platform reads from the top down: the first definition it finds wins. This guide walks through how layering actually works, with a worked example.

Power Platform solution layering 101 guide

Want the hi-res version? It's free in the Powercademy Success Kit.


What are solution layers?

Stacked versions of the same component - a table, column, form, app, or flow. Managed layers sit at the bottom in install order, with the last-installed managed solution taking precedence over earlier ones. Above all managed layers sits the unmanaged (active) layer, which holds every ad-hoc tweak and imported unmanaged solution. Picture each change as a transparent sheet stacked on the last: at runtime the platform reads from the top down, and whatever is on the top sheet is what users see.


How does layering play out in practice?

Follow one field label through a production environment:

  1. A vendor's solution (Managed A) sets the label to "Name" and deploys to production. Users see "Name".

  2. Your team's solution (Managed B) changes it to "Full Name" and deploys. Managed B sits above Managed A, so users see "Full Name".

  3. Someone makes an accidental change directly in production, setting "Customer Name". That lands in the unmanaged layer - the very top - so users see "Customer Name", and your future deployments to this field stop being visible.

  4. You select Remove active customisations, which drops the unmanaged layer. Back to "Full Name".

  5. Uninstall Managed B and the platform falls through to the next layer down. Back to "Name".

That one sequence explains most layering mysteries: the unmanaged layer silently eating deployments is the classic. It is why changes should never be made directly in production - they don't just risk breaking things, they mask every future deployment of that component.


How do you inspect and clean up layers?

Navigate to the component inside your solution, then choose the ellipsis, Advanced, and See solution layers to view the full stack. To drop an unmanaged top layer, use Remove active customisations - but know that it is irreversible for that layer, so confirm the managed solution underneath has the behaviour you want first. If the unmanaged item is the only layer, there is nothing underneath to fall back to, and you would delete the component instead. The working rules: keep dev unmanaged and test/production managed, never edit directly in test or production, aim to contain components in a single solution where possible, and never delete unmanaged customisations without consulting whoever owns the solution.

Howdang’s Implementation Tip

When a deployed change refuses to appear, check See solution layers before anything else. Nine times out of ten there is an unmanaged layer sitting on top of your managed solution, left behind by a well-meaning production tweak. Removing it fixes the 'broken' deployment instantly - no redeploy needed.


FAQ

Why does my deployed change not show up in production?

Almost always an unmanaged layer: someone edited that component directly in production, and their version now sits above your managed solution. See solution layers confirms it; Remove active customisations resolves it.

Which managed solution wins when two change the same component?

The one installed most recently - managed layers stack in install order, latest on top. That ordering is also why install sequence matters when solutions depend on each other.

Is Remove active customisations safe?

It permanently discards the unmanaged layer for that component, so it is safe only when the managed layers underneath hold the intended behaviour. Check the layer stack first, and involve the solution's owner if you are unsure what the unmanaged layer contains.

Do solution layers exist in dev environments too?

Yes - layering works everywhere, but in dev your work deliberately lives in the unmanaged layer because that is where components are edited. The discipline only inverts at test and production, where everything should arrive managed and the unmanaged layer should stay empty.


The hi-res version is in the Powercademy Success Kit - free, along with hundreds of other cheat sheets, roadmaps, and guides for Microsoft professionals.

For teams

Putting this into practice at your organisation?

This is the work we do with businesses every week: custom workshops built around your systems, architecture advisory while your team builds, and fixed-price implementation. Every engagement is covered by our results guarantee.

See how we work with teams30-minute discovery call. No obligation.
PowercademyPowercademy

The training platform for Power Platform professionals.

Free Success Kit

Cheat sheets, guides & frameworks - plus the weekly briefing.

Get the free Success Kit

Product

  • Courses
  • Community
  • News
  • Blog

For Businesses

  • Overview
  • Workshops
  • Advisory
  • Implementation

Legal

  • Privacy Policy
  • Terms of Service

© 2026 Powercademy. All rights reserved.

Keep reading

The Power Platform ALM Cheat Sheet

Environment types, managed vs unmanaged solutions, deployment options, and the factors that shape environment strategy - Power Platform ALM on one page.

The Power Platform ALM Learning Roadmap

From solution framework principles to full CI/CD - the eight-stage roadmap for learning Power Platform ALM, in the order that actually builds on itself.

Manual Deployments vs Power Pipelines vs Azure DevOps: Which Should You Use?

Three ways to move Power Platform solutions between environments - hands-on manual imports, built-in Power Pipelines, and full Azure DevOps CI/CD. When each one is the right call.