Why use managed solutions

Every now and then I get asked why someone should use managed solutions. We also had a discussion internally recently because some of our projects have problems with it. The same discussion came up in the Power Platform Level Up discord. This blog post tries to summarize those discussions and give insights to a broader audience.

If you are not part of the Power Platform Level Up discord I highly recommend doing it. It’s an open Server for Power Platform developers. There are always great discussions and insights.

During the mentioned discussions I gathered a list of arguments for and against managed solutions. Let’s dive into those. Please let me know when you have other arguments which I have not mentioned here. I would be happy to add them to the list (including a shout-out of course).


Let’s begin with the arguments for managed solutions or advantages.

Clean up

My biggest plus for managed solutions is that they “clean up”. This means when there is a component removed from the solution and the solution is installed as a managed upgrade to the target environment the component will be deleted from the target environment automatically. This also works when there have been several update deployments in between. The main advantage of this is that one does not have to remember that there are components he/she has to remove from the downstream environments manually.

Please be aware that in some situations problems can arise when you try to clean up (or delete) too many components/dependencies with one deployment.

Easier management of multiple teams

Managed solutions make it easier to manage multiple teams. This is because we can make use of publisher separation as well as we can define what others can do with components (using managed properties).

Prevent deletion by mistake

Components installed as managed are harder to delete. Which protects them from being deleted from production by mistake. At least it is harder to delete them (some aren’t even possible to delete at all).

Make use of Layering

Every managed solution gets a separate layer in Microsoft’s Solution Layering. One can make use of this to determine/predict the behaviour shown to the end-user. In addition, some components (Mode-Driven apps, Site maps and Forms) use merge behaviour when different layers change the same component. Whereas the other components use the “Top Wins” behaviour.

The ability for Solution segmentation

With the mentioned Layering we can also use segmented solutions. In theory that is possible with unmanaged solutions as well, but will result in less predictable behaviour as well as potentially cross dependencies.

Ensure transportation of settings

There are some settings (like for example audit settings and table metadata) that might not get installed correctly when using an unmanaged solution.

Faster deployment using Update

When the correct settings (see my latest blog post about this) are used a managed import might be faster than an unmanaged import.

Microsoft best practice

Microsoft is recommending using managed solutions as well as it is considered their best practice. The development in this area in the last few months let me guess that Microsoft might only allow managed solutions in environments of the type of production sometime in the future. In the recent Release Notes, there is a topic called “Take advantage of pipelines” for managed environments. In the details, you can see that admins will have the option to “lock down” production-type managed environments to only allow installation of managed solutions already soon.

Pipeline in Power Platform only uses managed

Pipeline in Power Platform only use managed solutions. Those are considered the ALM way for citizen devs. This means citizen will have to learn the pros and cons of managed solutions. This will make them more accepted.

Dependency issues aren’t magically resolved using unmanaged solutions

Sometimes I hear the argument that people get dependency errors when they switch from unmanaged to managed solutions. Unmanaged solutions do not magically solve dependency problems. They usually hide them away. Which means there have been problems/errors while handling solutions earlier.


Even managed solutions, as with everything, have disadvantages. Here are the 3 I could think of.

Handling of Secuity Roles

Security Roles get overwritten with every import. For me they have not followed any of the mentioned behaviours other than last installed wins. This technically could also happen with unmanaged solutions though.

Layering Choice fields

Choice fields might not show the result you would expect. Sometimes deleted values do come back after Microsoft does some update.

Increased effort for separating solutions

Since dependency issues are more visible there has to be more focus and effort when it comes to solution separation.

Some connectors

Some connectors, like for example the SharePoint connector is some scenarios, require that one edits flows after deployment. Which might be a bit harder in a managed solution setup.

I am pretty sure I have not listed all of them.


I am definitely on the managed side. For me, it is the way forward and should be used in all environments which are not development.

I hope this post was helpful and please let me know what you think.

This is just 1 of 60 articles. You can browse through all of them by going to the main page. Another possibility is to view the categories page to find more related content.
You can also subscribe and get new blog posts emailed to you directly.
Enter your email address to receive notifications of new posts by email.

  1. Avatar

Add a Comment

Your email address will not be published. Required fields are marked *