What Is an Unmanaged Solution in Dynamics 365?

Every customization in Dynamics 365 lives in a solution. Whoever creates a field, builds a view or writes a flow always does so within such a container, even without consciously choosing one. The unmanaged variant is the one in which the actual work should happen.

What an unmanaged solution contains

It is not a folder of files but a collection of references. The solution remembers which tables, fields, forms, views, processes and web resources belong to it. The components themselves live in the environment.

When you export it, you get a ZIP file with three central parts: a solution.xml with the metadata and the list of contained components, a customizations.xml with the actual definitions and, depending on the content, further folders for web resources, flows or canvas apps, for example.

The decisive behavior

Two properties distinguish the unmanaged solution from the managed one.

First, everything remains editable. A field that arrives in an environment through an unmanaged solution can be renamed, changed or deleted there.

Second, membership is loose. If you delete the solution, the components do not disappear. They stay behind in the environment, just without the container. That sounds harmless, but in practice it leads to orphaned customizations that nobody can attribute anymore.

Why it does not belong in production

In the development environment, the unmanaged solution is exactly right. There you need to be able to change and discard things. Or you may need to assign components to several solutions.

In test and production the advantage turns around. There, editable means: anyone with the right privileges can tinker directly with the form, and development never finds out. At the next deployment, two states may then collide, each of which looks plausible on its own.

The second effect is subtler. Unmanaged customizations sit in the layering above everything delivered as managed (a so-called solution layer). Whoever later delivers a corrected version as a managed solution finds that it does not take effect, because the old unmanaged change sits on top and wins. Free tools that make these layers visible are listed in the overview of free analysis tools.

How to tell what you are dealing with

In the solutions overview in Power Apps, a column shows the type. If you only have the ZIP file, open the solution.xml and look for Managed: a 0 means unmanaged, a 1 means managed.

Less obvious is the question whether an environment contains unmanaged customizations to components that actually come from managed solutions. It is exactly this mixed form that causes most surprises during deployments.

Practical consequence

The comparison of both variants with their consequences can be found under managed vs. unmanaged.

A clean setup looks like this: in development, work is done unmanaged; for test and production, the export is managed. That keeps the development environment the only place where customizations are created, and nobody can intervene in production unnoticed. Before the very first solution, one more permanent decision is due: choosing publisher and prefix.

There are reasons to deviate from this. But then please write them down, with date and name. Anything else will come back to bite you.