Managed solution (Power Platform)

What is a managed solution?

A managed solution is a packaged Power Platform release that you install into an environment as a finished, managed product. It is meant for the environments where an app runs rather than where it is built: test, user acceptance, system integration, and production.

The package carries component definitions, for example apps, Dataverse tables, columns, cloud flows, security roles, and plug-ins. When you import it, those components form a managed layer that sits on top of the platform's own system layer.

You cannot edit the components of a managed solution directly. To change one, you first add it to an unmanaged solution, which creates a dependency the platform tracks. This is the deliberate trade: a managed solution is stable and serviceable because it is not meant to be edited in place.

From unmanaged source to managed artefact

Makers build in a development environment inside an unmanaged solution. You do not author a managed solution. You export the unmanaged one as managed, and that export is the release.

Treat the exported file as a build artefact. Give it a version, keep exactly that file, and promote the same build through test and then production. Rebuilding a fresh export at each stage can quietly ship different content, so one immutable file per release is the safer habit.

A managed export is not a copy of the whole environment. Business records, users, and many environment-specific connections are set up separately in each target. The solution moves the customisations, not the data.

Managed properties

Managed properties decide which parts of a component a downstream environment is allowed to change. The publisher sets them before the managed export, and an administrator in the target environment cannot loosen them freely afterwards.

A managed property is not a licensing or secrecy control. It stops certain customisations, but it does not hide client-side code and it is no substitute for real access security. Allow changes where a customer or internal admin genuinely needs them, such as a label, and protect the core components whose local edits would break support and future upgrades.

Updates, upgrades, and patches

These three servicing paths behave differently, and the difference matters when a component has to disappear.

Update. An update deploys over the previous version of the same managed solution without adding a new layer. It changes and adds component definitions, but it cannot delete components that were dropped from the new version.

Patch. A patch carries only the changes for its parent managed solution and layers on top of it. It suits a small, hotfix-style change that you may want to remove later. A patch also cannot delete components.

Upgrade. An upgrade installs a new layer above the base and any patches. A staged upgrade places a pending layer first; selecting Apply upgrade then flattens the layers into a new base, deletes the old patches and base layer, and removes any component that is no longer in the new version.

Because an upgrade can remove a column or table, and removing one can affect stored data, test the chosen path against a realistic copy before you run it in production.

Uninstalling a managed solution

Uninstalling removes the components the managed solution owns, as far as dependencies allow. That is real deletion: data held in custom tables that belong to the solution, and data in custom columns it added to other tables, is lost with it.

So check dependencies, data retention, and your recovery plan before you uninstall. Being able to remove a managed solution cleanly does not make uninstall a safe rollback for every release. Schema and data changes usually need their own recovery plan.

Managed versus unmanaged

An unmanaged solution is a development container. Its edits land in the environment's single active unmanaged layer and survive when only the container is deleted, so removing the container does not undo the work.

A managed solution is an installable layer with a real lifecycle. Updates, upgrades, managed properties, and uninstall all follow the solution, and removing it does affect the installed components. The guidance from Microsoft is to keep everything outside development managed, and to avoid making direct unmanaged changes in production, because such a change creates an active layer that can override the runtime version you meant to ship.

A release example

Version 2.3 of a case-management app changes a form, adds a cloud flow, and adds one column. The pipeline builds a single managed artefact and imports it into test first.

After access and regression checks pass, the same file goes to production, where environment variables and connection references get their production values. The release log keeps the solution version, the source commit, the import result, and the configuration, so it is always clear which build is live and how the next upgrade should line up against it.