Managed vs Unmanaged Solutions 📦

Solutions are how you move apps, flows and tables between environments, the backbone of Application Lifecycle Management (ALM) in Power Platform. Getting managed vs unmanaged right early saves you from unpicking a tangled production environment later. Looking for Managed Environments (the governance feature) instead of managed solutions? See Unmanaged vs Managed Environments vs Routing.

TL;DR: Develop in unmanaged solutions (open, editable, your source of truth in source control). Deploy managed solutions everywhere else: test, UAT, production. Only your dev environment should contain unmanaged customizations.

At a glance

	Unmanaged	Managed
State	“Open”	“Closed” build artifact
Lives in	Dev environments	Test, UAT, production
Editing	Directly editable	Not directly editable
Add/remove components	Yes	No
Export	Unmanaged or managed	Can’t be exported
On delete	Only container removed	Removes components + data
Layer	One shared layer, on top	Its own discrete layer

What each one is for

Unmanaged: your source

🔸 Used while you build. Components are fully editable.

🔸 The exported unmanaged version is what you check into source control, so treat it as the source of truth for your Power Platform assets.

🔸 Deleting an unmanaged solution removes only the container; the customizations stay behind in the default solution.

Managed: your deployable

🔸 Created by exporting an unmanaged solution as managed, a versioned build artifact.

🔸 Deployed to every environment that isn’t the solution’s dev environment.

🔸 Can be serviced independently: upgraded, patched and uninstalled as a discrete layer.

🔸 Uninstalling a managed solution removes the components it owns, including data in custom tables/columns it introduced.

Solution layers in one minute

🔸 The unmanaged layer is a single layer holding all unmanaged solutions and ad-hoc customizations. It sits on top and wins at runtime.

🔸 Managed layers: each managed solution is its own layer. When several are installed, the last one installed sits highest; on conflicts it’s “last one wins” or a defined merge. Uninstall one and the layer below takes effect. At the base sits the system layer.

flowchart TD
    L1["Unmanaged layer<br/>your ad-hoc customizations, wins at runtime"]
    L2["Managed layer: last solution installed"]
    L3["Managed layer: earlier solution(s) installed"]
    L4["System layer<br/>Microsoft base"]
    L1 --- L2 --- L3 --- L4

ALM best practices (from Microsoft Learn)

🔸 Deploy only managed solutions to test and production to prevent unmanaged customizations from piling up.

🔸 Edit in dev only, then move changes downstream through your ALM process.

🔸 Use one solution publisher and keep the number of publishers to a minimum, since publisher ownership can’t be reassigned later.

🔸 Consider Pipelines in Power Platform to automate export/import and reduce human error.

Watch out

🔸 Don’t import a managed solution into its own dev environment. You can’t import a managed solution into the environment that holds the originating unmanaged solution. Use a separate environment to test managed.

🔸 Deleting managed means deleting data. Uninstalling a managed solution drops data stored in the custom tables and custom columns it owns. Know this before you uninstall in production.

🔸 Editing a managed component creates a dependency. To change a managed component you add it to an unmanaged solution, which then blocks uninstalling the managed one until you remove the dependency. Some components are locked by managed properties.

🛠️ FAQ

Can I convert an unmanaged solution to managed? You don’t convert in place, you export the unmanaged solution as managed and import that artifact into downstream environments. Keep the unmanaged export in source control.

Why shouldn’t production have unmanaged customizations? They live in the shared unmanaged layer, are hard to trace, and undermine repeatable deployments. Production should hold only managed solutions.

What happens if two managed solutions conflict? The last one installed sits highest; runtime resolves conflicts as “last one wins” or via defined merge logic. Uninstalling the top one lets the one below take effect.

Do solutions contain my business data? No, solutions carry metadata and configuration, not business data, with the exception of specific configuration tables you add. But uninstalling a managed solution deletes data in the custom tables/columns it introduced.

🔗 Related

🔸 Unmanaged vs Managed Environments vs Routing, the governance feature, not this page’s solution packaging.

🔸 All Dataverse tips

🔸 Dataverse vs SharePoint

🔸 Knowledge base overview

Concepts reflect Microsoft Learn ALM guidance at time of writing.