Managed vs Unmanaged Solution in Power Platform - [#shorts]
Daniel Cieckiewicz
What must you know about Solutions?
Solutions are essential in Power Platform. They are the containers for your solution, the work you do, and the business scenario you are implementing and expanding. Power Platform Solution allows you to take all your specific solution components and gather them together in an ordered way. So, we can call it a real solution – because it is structured, and you can quickly locate the components and dependencies.
One of the primary purposes of a solution is to migrate the specific solution (your built applications/flows/automation) within the environments. It allows you to provide DEV | TEST | PROD infrastructure for Power Platform and deploy a correct version of a solution. Thanks to that, you keep everything structured and secured.
Solutions also allow ALM (Application Lifecycle Management) to automate solution deployment and management.
There are two types of Power Platform Solutions. Managed and Unmanaged.
What is Unmanaged Solution?
Power Platform Unmanaged Solution is a type where you can build a solution, add components, remove them and play with many configuration parameters. This type of solution can often be encountered in a developer environment where Project Teams work on a specific solution, adding, removing, testing, and configuring particular components.
You can export Unmanaged Solution as Unmanaged or Managed.
If you remove your Unmanaged Solution from your environment, all components of this solution will stay untouched and ready to use.
Unmanaged solutions are used in development environments while you make changes to your application. Unmanaged solutions can be exported either as unmanaged or managed. Exported unmanaged versions of your solutions should be checked into your source control system. Unmanaged solutions should be considered your source for Microsoft Power Platform assets. When an unmanaged solution is deleted, only the solution container of any customizations included in it is deleted. All the unmanaged customizations remain in effect and belong to the default solution.
What is Managed Solution?
Power Platform Managed Solution is a solution where you cannot provide changes to the solution. You can’t add or remove components, and you cannot make modifications to the components themselves. This type of solution is often called a “Production Solution,” where you don’t want to make any changes. To prevent anybody from doing so, you disable the ability to provide such a change. After deploying a managed solution, you cannot transform it into an Unmanaged Solution.
Managed solution also enables Power Platform Developers to run ALM and automate the solution deployment process.
If you remove the Managed Solution from your environment, as distinct from the Unmanaged Solution, all components of that solution will be removed.
You can’t export Managed Solution.
Managed solutions are used to deploy to any environment that isn't a development environment for that solution. This includes test, UAT, SIT, and production environments. Managed solutions can be serviced independently from other managed solutions in an environment. As an ALM best practice, managed solutions should be generated by exporting an unmanaged solution as managed and considered a build artifact.
Managed or Unmanaged Solution - When to use?
When to use Unmanaged Solution?
It would be best if you used an Unmanaged Solution when you work on your developer environment, where you work with components, applications, automation, and more. This is easy as that. If you want to edit a component of a managed solution, it should be moved to the separate Unmanaged Solution – as Microsoft says:
You can't edit components directly within a managed solution. To edit managed components, first add them to an unmanaged solution. When you do this, you create a dependency between your unmanaged customizations and the managed solution. When a dependency exists, the managed solution can't be uninstalled until you remove the dependency.
When to use Managed Solution?
Managed solution should be used everywhere where Unmanaged solution should not. In a previous paragraph, I said an Unmanaged solution should be used in a developer environment. So, we should work with Managed Solution everywhere else. On PRE-PROD, UAT, or TEST environments.
You should be using Managed Solution if you want to set up ALM or you want to block the possibility of editing components.
As previously said, Managed Solution is a “Production Solution”, so you should consider what the “Production” term means for you.
It will help if you remember why you are deploying Unmanaged Solution to the environment – to the TEST environment, for example. If you did that, it must mean that you want to provide changes to your solution. So, if you provide changes to the solution deployed on TEST, you must move those to the DEV environment. It doesn’t make any sense. Plan your actions and remember about pros and cons of Managed and Unmanaged solutions.
What components are allowed in a Solution?
There are tons of components you can add to a solution. Here are some of them:
- Tables
- Columns
- Choices
- Environment variables
- Connection References
- Applications
- Cloud flows
- Desktop flows
- Processes
- Security roles
- Components dependencies
- Component libraries
- and more..
What about a Solution's Publisher?
Publisher is an owner of a solution’s components. It tells you who owns the components and who created them. Publisher is used to publishing the solution’s components and allows developers to identify components of specific solutions. Identifying a solution component is straightforward because every publisher has a prefix that is automatically added to the component’s name when created within the solution. Components that are added to the solution (not created in the solution) won’t have this prefix added. They already have a default one.
Microsoft suggests using the same publisher across different environments for the specific solution. It will allow you to quickly locate and manage the solution, especially in the ALM process. Remember also that you will not be able to move the component between different publishers using the managed solution.
In the end, let’s hear what Microsoft says about Publishers in Power Platform Solutions.
Every app and other solution components such as entities you create or any customization you make is part of a solution. Because every solution has a publisher, you should create your own publisher rather than use the default. You specify the publisher when you create a solution. The publisher of a solution where a component is created is considered the owner of that component. The owner of a component controls what changes other publishers of solutions including that component are allowed to make or restricted from making. It is possible to move the ownership of a component from one solution to another within the same publisher, but not across publishers. Once you introduce a publisher for a component in a managed solution, you can’t change the publisher for the component. Because of this, it's best to define a single publisher so you can change the layering model across solutions later. The solution publisher specifies who developed the app. For this reason, you should create a solution publisher name that's meaningful.
Here is a link to the full Microsoft article about Power Platform Solutions: Solution concepts.
Summary
In summary, solutions in Power Platform are essential – as I said in the introduction. They allow us to work with different components – applications, automations, and integrations, thereby keeping everything structured and secured. If you created a system composed of many other components, it would be a nightmare to migrate it through environments. This is where solutions are beneficial, allowing developers to migrate entire systems between environments.
Remember, there are two types of a Solution – Managed and Unmanaged. Remember the pros and cons of using them. Remember the best practices I showed in this article and take your knowledge, especially the approach, to the next level!
So, finally, we are at this point where I should thank you for your time and reading this article. Feel free to rate this article and comment if you liked it. If you have any questions, feel free to contact me (via contact@poweruniverse.org), but first, you may be interested in joining a Newsletter. Hmm? (Sign up here) If you already did, wow, thanks, thanks a lot.
Via Newsletter, I am sharing insights into my work, plans for upcoming weeks, and knowledge about Power Platform Universe and the IT world. If you are interested, feel free to join! I am going to send the latest Newsletter to everyone who enters!
See you!
Daniel Ciećkiewicz
I am a Senior Power Platform Consultant focused on Dataverse, Power Apps, and Power Automate. I was also a Team Leader responsible for the Power Platform Team and their development paths.
In my private life, I like video games, sports, learning & gaining knowledge, and a taste of good Scotch Whisky!
Ooo, I almost forgot, I love our Polish Tatra Mountains!
Power Apps Licensing Explained
Power Apps Licensing – this is something every Power Platform expert must know. In this article I will walk you through the cons and pros of available plans.
Understand Delegation in Power Apps
In this article I will walk you through delegation in Power Apps and I will show you many interesting concepts how to work with delegation and understand Delegation in Power Apps!
Connection vs connection reference in Power Platform
In this article I will tell you what is the difference between connection and connection reference in Power Platform. It is very good to know the advantages.
Overview of a Tenant Isolation in the Power Platform
What is Tenant Isolation in the Power Platform? How does it work and how do you know it will be good for your organization? Check the article!
The most interesting Power Platform features of 2024 – Wave 1 update
Do you want to know what updates are coming in 2024? This article will tell you more about incoming updates for Power Platform in Wave 1.
Use a Service Principal to run Dataverse actions in Power Automate
Do you want to learn how to use a Service Principal to work with Dataverse actions in Power Automate? This article is for you. Check it out.