Events
Powerful Devs Conference and Hack Together
12 Feb, 11 pm - 28 Feb, 11 pm
Join the online conference and 2-week hackathon to explore building powerful solutions with Power Platform.
Register nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Solutions are the mechanism for implementing application lifecycle management (ALM) in Power Apps and Power Automate. This article describes the following key solution concepts:
A solution is either managed or unmanaged.
Unmanaged solutions are developed. 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's deleted. All the unmanaged customizations remain in effect and belong to the default solution.
Managed solutions are deployed. Managed solutions are deployed to any environment that isn't a development environment for that solution. These environments include test, user acceptance testing (UAT), system integration testing (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. Additionally:
Important
Makers and developers work in development environments using unmanaged solutions, then import them to other downstream environments—such as test—as managed solutions.
Note
When you customize in the development environment, you're working in the unmanaged layer. Then, when you export the unmanaged solution as a managed solution to distribute to another environment, the managed solution is imported into the environment in the managed layer. More information: Solution layers
A component, also known as objects, represents something that you can potentially customize. Anything that can be included in a solution is a component. To view the components included in a solution, open the solution you want. The components are listed in the Components list.
Note
To view a list of component types that can be added to any solution, go to ComponentType Options.
Some components are nested within other components. For example, a table contains forms, views, charts, columns, tables relationships, messages, and business rules. Each of those components requires a table to exist. Except for choice columns, all other columns can’t exist outside of a table. We say that the column is dependent on the table. There are twice as many types of components as shown in the preceding list, but most of them are nested within other components and not visible in the application.
The purpose of having components is to keep track of any limitations on what can be customized using managed properties and all the dependencies so that it can be exported, imported, and (in managed solutions) deleted without leaving anything behind.
Solutions support the following actions that help support application lifecycle processes:
Every app and other solution components such as tables 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.
Note
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's 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 restriction, 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.
A solution publisher includes a prefix. The publisher prefix is a mechanism to help avoid naming collisions. This allows for solutions from different publishers to be installed in the same environment with few conflicts. For example, the Contoso solution displayed here includes a solution publisher prefix of contoso.
Note
When you change a solution publisher prefix, you should do it before you create any new apps or metadata items because you can't change the names of metadata items after they're created.
More information:
Because of the way that managed solutions are layered, some managed solutions can be dependent on solution components in other managed solutions. Some solution publishers take advantage of this to build solutions that are modular. You might need to install a "base" managed solution first and then install a second managed solution that further customizes the components in the base managed solution. The second managed solution depends on solution components that are part of the first solution.
The system tracks these dependencies between solutions. If you try to install a solution that requires a base solution that isn’t installed, you won’t be able to install the solution. You get a message saying that the solution requires another solution to be installed first. Similarly, because of the dependencies, you can’t uninstall the base solution while a solution that depends on it's still installed. You have to uninstall the dependent solution before you can uninstall the base solution. More information: Removing dependencies
A solution component represents something that you can potentially customize. Anything that can be included in a solution is a solution component and some components are dependent on other components. For example, the website column and account summary report are both dependent on the account table. More information: Dependency tracking for solution components
Solution layers
Create and manage environments in the Power Platform admin center
Events
Powerful Devs Conference and Hack Together
12 Feb, 11 pm - 28 Feb, 11 pm
Join the online conference and 2-week hackathon to explore building powerful solutions with Power Platform.
Register nowTraining
Module
Manage solutions in Power Apps and Power Automate - Training
Learn how to manage solutions in Microsoft Power Apps and Power Automate.
Certification
Microsoft Certified: Power Platform Solution Architect Expert - Certifications
As a Microsoft Power Platform solution architect, you facilitate design decisions based on recommended practices across development, configuration, integration, infrastructure, security, licensing, storage, and change management.