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).
Advantages
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.
Disadvantages
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.
Conclusion
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.
You can also subscribe and get new blog posts emailed to you directly.
[…] Why use managed solutions ” Benedikt’s Power Platform Blog […]
How do you deal with an issue related to Security roles? Is keeping them in a dedicated solution a good approach?
This depends on the issue you are facing.
In general I don’t have security roles in different solutions.
Let’s say I have 2 development environments (A & B) and 2 solutions (1 & 2). Environment A has Solution 1 as unmanaged and Environment B has Solution 1 as managed and Solution 2 as unmanaged.
Solution 1 contains a security role which you would like to alter in Solution 2. I would create a new security Role, adding the needed permissions, rather than altering the Security role from Solution 1.
I would add one more for unmanaged as an advantage, next to no possibility of a mistake causing irrecoverable data loss. Accidentally uninstall a managed solution (shocker, we are all human and people make mistakes) and you’ve lost your data. Recovery could be impossible or extremely difficult. Unmanaged when uninstalled actually doesn’t remove anything. This can be a pro/con depending on the type of app, environment, criticality of the app, industry, etc.
I would always suggest to go managed if you can but management, clients, and your team makeup all affect that.
Hej Joe,
thanks for your comment.
I do agree, that the team and client have huge impact on that (as on all architectural decisions).
I would not go unmanaged because of the risk of someone does some errors though. This should be handled by educating users and only giving access to solutions in production to those that really need it.