Managed vs Unmanaged Solutions, Explained Properly

If you’ve spent any time around Dataverse, you’ve seen the prompt: when you export a solution, you have to pick Managed or Unmanaged. New makers usually guess. Experienced ones sometimes guess too, because the docs explain the mechanics without explaining the why.

Here’s the short version, and then the part that actually matters.

What the Two Words Mean

An unmanaged solution is a working layer. Everything inside it — tables, columns, forms, flows — is editable directly. You can open a form and drag a field onto it. You can add a column without going through a deployment. It behaves like a project you’re actively building.

A managed solution is a package. Once you import it, the components inside are locked from direct editing in that environment. You can’t drag a field onto a managed form. You can’t delete a managed column. To change anything, you go back to the source — wherever the unmanaged version lives — and ship a new version.

That’s the entire mechanical difference. The confusion comes from when to use which.

The Rule That Actually Works

Unmanaged in dev. Managed everywhere else.

You build and iterate in an unmanaged solution inside your development environment. That’s where things should be editable, because you’re actively changing them. When you’re ready to move forward, you export as managed and import that package into test, UAT, and production.

Production should never contain an unmanaged solution that you built directly in it. If it does, you’ve lost the ability to cleanly version, roll back, or know what’s actually in that environment versus what a user clicked together by hand.

Why People Get This Wrong

“Managed feels restrictive, so I’ll use unmanaged everywhere.” This is the most common mistake. Unmanaged solutions in production mean anyone with System Administrator access can edit a form, delete a flow, or change a column — directly, with no record of it going through your release process. Six months later nobody can explain why a “deployed” environment looks different from what’s in source control, because it never went through source control. It was edited live.

“I’ll just delete the managed solution if something’s wrong.” Deleting a managed solution removes everything it owns — tables, data in those tables, flows, the works — unless other solutions still hold a dependency on those components. This is not a quick way to undo a bad deployment. Treat managed solution deletion as seriously as you’d treat dropping a database.

Layering managed solutions. You can import a managed solution on top of another managed solution that touches the same components. Dataverse merges them using a layering model — the most recently applied managed layer generally wins for a given property. This is how ISV solutions and your customizations coexist, but it also means two managed solutions changing the same field can produce a result neither author intended. If you’re layering, know what’s underneath you.

What Goes Wrong Without This Discipline

A typical failure mode: a team builds directly in production because “it’s faster,” using an unmanaged solution with no formal dev environment at all. It works, until two people edit the same form in the same week and one set of changes silently overwrites the other. Nobody notices until a user reports a missing field three weeks later.

The fix isn’t a process document — it’s removing the option. If production only accepts managed imports, nobody can casually click a change into existence. The deployment pipeline becomes the only path in.

Working With Both Day to Day

A few habits keep this clean:

• One unmanaged “source of truth” solution per dev environment. Don’t scatter components across multiple unmanaged solutions for the same project — it makes exporting consistently nearly impossible.
• Increment the solution version on every export. 1.0.0.1, 1.0.0.2, and so on. Without this, you can’t tell which package is actually sitting in an environment.
• Use Power Platform pipelines or Azure DevOps to move solutions, not manual export/import. Manual import is fine for a solo project; it doesn’t scale past one person without someone eventually importing the wrong file.
• Never edit a managed environment to “just fix it quickly.” If a managed environment lets you make the edit, that means an unmanaged layer exists underneath — which usually means the environment isn’t as locked down as you think.

The One-Sentence Version

Unmanaged is for building. Managed is for shipping. If you remember nothing else, that’s the part that keeps environments predictable.