Managed and unmanaged solutions, explained simply

Managed and unmanaged solutions are one of the first things you run into in Power Platform, and one of the things that causes the most confusion. Why doesn’t my change show up in production? Why can’t I edit this flow? Why does this form have three layers?

In this post I’ll go through it from A to Z, as simply as I can.

What is a solution?

A solution is a container for everything you’ve built: tables, columns, forms, views, apps, flows, environment variables and so on. It lets you move your work from one environment to another as a single package, instead of recreating everything by hand.

Solutions come in two flavours: unmanaged and managed.

Unmanaged: the working version

Think of a Word document. You can write, delete and change as much as you like. That’s how an unmanaged solution works.

• You can edit every component directly.
• The solution is really just a list of what belongs together. The components themselves live in the environment.
• If you delete an unmanaged solution, only the list disappears. The tables, flows and forms stay behind.

That last point surprises a lot of people. You can’t “uninstall” an unmanaged solution.

Managed: the finished package

Think of a PDF made from that Word document. It’s finished, locked and meant to be used, not edited. That’s a managed solution.

• You create it by exporting an unmanaged solution as managed from the development environment.
• Its components usually can’t be changed directly where it’s installed.
• It can be uninstalled. That removes all the components it added.

Why unmanaged in development, but managed everywhere else?

The development environment is the workshop. You need to be able to change things freely there, so that’s where you work unmanaged.

Every other environment should get exactly what was tested, and nothing else. That’s why you install managed there:

Environment	Type	Why
Development	Unmanaged	This is where you build and change freely
Test	Managed	You test what’s actually going to production
QA	Managed	The same package that moves on
Production	Managed	Locked, traceable and possible to roll back

Some teams use unmanaged in a test environment too, so they can make quick fixes. It’s tempting, but then you’re testing something different from what ends up in production, and those fixes have to be remembered and redone in development. My recommendation is managed everywhere except development.

Layers: how it all fits together

This is where it gets interesting. Every time a solution changes a component, the change is added as a layer on top of what was already there. Think of it as transparent sheets stacked on top of each other.

Here’s what the layers for a form might look like:

1. Active layer (unmanaged)Changes made directly in the environment
2. Managed: Customer Service 2.0Installed last
3. Managed: Customer Service 1.0Installed first
4. SystemMicrosoft's defaults

Three things are worth knowing:

1. The system layer is always at the bottom. It’s Microsoft’s default setup.
2. Managed layers stack up in the order they’re installed.
3. The active, unmanaged layer is always on top. Anything changed directly in the environment ends up there.

For most components, the top layer wins. Users see whatever the highest layer that changed a given property says. Forms, site maps and the ribbon are the exceptions: there the layers are merged, so changes from several solutions can live side by side.

You can see the layers yourself: open a solution, select a component and choose See solution layers.

What happens when you put an unmanaged layer on top?

Say you’ve installed a managed solution in production, and someone makes a “quick fix” directly in the environment. The change lands in the active layer, right at the top.

The next time you install a new version of that managed solution, the new version goes in underneath the active layer. The manual change is still on top, and it wins. Your new version is installed, but users don’t see it.

That’s where the classic question comes from: “I imported the new version, so why can’t I see the change?”

How publishers affect the layers

Every solution has a publisher. The publisher says who owns the components, and gives them a prefix, for example edm_customernumber.

• Same publisher, new version: When you upgrade a solution from the same publisher, the new version replaces its own layer.
• Different publishers on the same component: If two solutions from different publishers change the same form, each gets its own layer. The one installed last sits on top.
• Uninstalling reveals the layer below: Remove the top solution, and the layer underneath comes back.

A common example is a third-party solution from a vendor, with your own customisations in a separate solution on top. They each sit in their own layer, and you can update either one without overwriting the other.

Example: the form with three layers

Picture the Contact form in production:

1. The vendor’s solution (publisher: Vendor Ltd) adds a “Membership” tab.
2. Your solution (publisher: you) adds a “Customer number” field and moves “Phone” to the top.
3. A power user moves “Customer number” to the bottom, directly in production.

Because forms are merged, users see both the vendor’s tab and your field. But the position of “Customer number” comes from the active layer, which is the power user’s change.

Next week you ship a new version where “Customer number” should sit next to “Email”. You import it, everything goes green, and nothing happens. The power user’s layer is still on top.

Example: the flow that wouldn’t update

This happens a lot with Power Automate.

A flow sends an email when a case is created. It lives in a managed solution in production. One day it fails, and someone opens the flow in production and fixes the recipient address on the spot. The flow works again, and everyone’s happy.

What they didn’t notice is that editing it created an unmanaged layer on top of the managed flow.

A month later you build a new version of the flow in development, with better error handling. You import the new version into production. But production still runs the old, manually fixed version, because the active layer wins. Your new flow sits safely underneath, unused.

The fix is to remove the active layer. Then the new version comes through.

Why layers upon layers become a problem

Layers themselves aren’t a problem. They’re actually a safety mechanism:

• Nothing is overwritten for good. Each solution has its own layer, and can be removed without breaking the others.
• You can always roll back. Uninstall a solution, and whatever was underneath comes back.
• A vendor’s solution can be updated without deleting your customisations, and the other way round.

The problem starts when layers pile up that nobody is in control of, especially unmanaged layers in test and production:

• Updates don’t seem to work, because an active layer sits on top.
• Environments drift apart. Production is no longer the same as development, and nobody quite knows why.
• Troubleshooting takes ages, because you have to dig through the layers to find out which change actually applies.
• Changes only exist in one place. A quick fix in production doesn’t exist in development, and gets lost or causes conflicts later.

How to clean up

1. Open the component in a solution and choose See solution layers.
2. Check whether there’s an active (unmanaged) layer on top, and what it contains.
3. Make sure the change you want to keep exists in development.
4. Remove the active layer with Remove active customizations.

Good habits

• Build unmanaged in development, and install as managed everywhere else.
• Don’t make changes directly in test or production. Make them in development and send them on.
• Use one publisher of your own with a fixed prefix.
• Don’t import an unmanaged version into production “just this once”. It lands on top and stays there.
• Use Upgrade when importing new versions. That also removes components you’ve deleted in development.
• Automate the flow between environments with Power Platform Pipelines or Azure DevOps, so you don’t need manual imports.
• Use managed properties to decide what can be customised in the target environment.

In short

Unmanaged is for building, managed is for delivering. Every solution adds a layer, and the top layer wins, except for forms, where layers are merged. Layers protect you, but an unmanaged layer in production can mean new versions never show up.

Keep production free of manual changes, and you’ll avoid most of the surprises.