The Microsoft Power Platform is great for quick and easy solutions and workflows. While developing a new Power App or flow is quick, governance and management can present some hurdles. Well, there is help for some topics, such as the use of solutions. Read more here.
For a brief overview of governance for the Power Platform, have a look at Power Platform Environments and Governance Tips. Here we start with a very basic overview of administration and environments.
Environments as a base
The default environment is special, but administrators can create environments for different purposes. We recommend creating environments for specific areas of application, such as for development, departments, the Center of Excellence, and similar projects.
Read more about environments at Establishing an environment strategy, Create and manage environments in the Power Platform admin center, and at Power Platform Environments and Governance Tips.
When we look into the Power Platform admin center, Resources / Capacity / Dataverse module, we see that every environment requires 1 GB of Dataverse capacity (except the Developer environment).
This is, because all content of the environment, like Power Apps, Flows, Connections, and other objects must be stored somewhere. The Dataverse is the place for all metadata, including a bunch of information, like the name, Id´s, owner, dates of access, and so on. The 1 GB is always reserved for the content of the environment, so to speak for the management. You can only create as many environments as you have capacity in your tenant. See more at New Microsoft Dataverse storage capacity.
The Environment Admins can be managed in the environment settings, depending on the type of environment. The Power Platform distinguishes between
- Environments without a Dataverse database and
- Environments with a Dataverse database
Environment Admins can perform all administrative actions on an environment, like managing users and roles, view and manage all resources within an environment, etc. Environment Makers can create new resources in the environment, including apps, connections, custom APIs, gateways, and flows using Microsoft Power Automate. Therefore, any user who should be able to create a new resource must be assigned the Environment Creator role.
In Environments with a Dataverse database, the System Administrator role is the equivalent of the Environment Administrator role.
Note: Existing apps and flows are not automatically visible for the Administrators of an environment. So don't get confused. Only resources shared with the administrator are visible to the administrator. Of course, the admin can grant himself permissions for existing resources, for example with PowerShell, see my modify-app-roles.ps1 script in my GitHub repo.
See more at Configure user security to resources in an environment - Predefined security roles.
The definition at Solutions overview says: "Solutions are used to transport apps and components from one environment to another or to apply a set of customizations to existing apps." - and this is exactly what they are for. You can create your own solution with related components. The Center of Excellence is an example of this. It is important that there are two types of solutions and the following rules apply:
- Managed solutions
- used to deploy to any environment that is not a development environment
- the user cannot edit components directly
- cannot be exported
- Unmanaged solutions
- used in development environments, while you make changes to the application
- content can be changed
- can be exported
- A managed solutions cannot be imported into the same environment. You need to import it to another environment for testing.
See more details at Managed and unmanaged solutions. The following graphics from the documentation illustrate the purpose of using solutions very well.
Working with solutions
In real life, the solutions help to transport and deploy applications, especially when the application consists of more than one resource. One of the first things to know is that solutions depend on a Dataverse database environment. Otherwise you will receive corresponding information.
So, using solutions comes with the cost of a Dataverse environment (see capacity information). But you can easily create the database here. Alternatively, the Power Platform Admin can add the database in the environment in the PPAC. It can take some minutes until the new database is ready to use in the environment.
As we can see, adding a Dataverse database creates some predefined solutions in the environment. Some are managed, and some are unmanaged.
The unmanaged Default Solution is described as a special solution that contains all components in the system that is useful for discovering all the components and configurations in your system. Usually, it is not recommended to use the default solutions to manage customizations, and it cannot be exported. See more at Use a solution to customize.
Create a new solution and add resources
To create a new application, use a new solution, as here.
Now e can add (new or) existing resources like apps and flows to our new environment. For example, we select two canvas apps and one flow that aren't in solutions yet. This will also add them to Dataverse, see Overview of working with solutions.
Note: Not all resources can be added to a solution, there are some limitations. Again, it depends on the type of resource (unfortunately). For example, flows with "indexed connectors" that cannot be added to a solution include Power Automate instant (button) flows, Power Apps, Teams, SharePoint, Microsoft Forms, Excel Online, Microsoft Project, Project Online, and some more. See them at Known limitations. This can be a major limitation of using Solutions, but it is what it is.
Checked that. I could not add flows with a Power Apps trigger to my solution. I added a flow with a scheduled time trigger. In the end, I added 2 apps, 1 flow, and I created 2 environment variables. appsetting1 with no default value, and appsetting2 with a default value of "green".
This is the content of mysolution1.
The button Publish all customizations button is for: "Customizations are automatically published when new items are created or existing items are deleted. You must publish changes after updating table definitions or tables that affect the user interface. You can decide to wait and publish a set of related changes together. Only published customizations are exported with a solution. You should always publish customizations before exporting a solution.". See Publish customizations.
Publish all changes
When you export an unmanaged solution, only published components are exported. Therefore, it is recommended to run the Publish all changes function to make sure all components are included in the exported solution.
After publishing, the behavior for environment variables acts like after the importing process. We added a default value for appsetting2 (green) only. We see that the solution asks for the other variables with no default value - they could be required for the application. The admin can add the desired value for that. Here, we leave that variable empty.
Export a solution
The solution is now ready for exporting. We can do so in the context menu.
Continue with Next on the "Before you export" panel (with the option to Publish and to check for issues). Now comes the important part: Export as managed, or as unmanaged solution?
The export can take several minutes to complete and creates an export .zip file to download. When I export both types, I get mysolution1_1_0_0_1_managed.zip, and the unmanaged solution in a file mysolution1_1_0_0_2.zip. See more about exporting at Export from Power Apps.
Usually, a solution is exported as managed solution. An unmanaged solution makes sense only, if you want to add all the components to your default solution and overwrite any existing customizations.
Import a managed solution
The import solution feature allows to upload the solution file and deploys the components into the target-environment. The following rules apply:
- Generally, only solutions from a trusted source should be imported.
- When you import a managed solution, all component changes will be brought into the environment in a published state.
- When you import an unmanaged solution, the changes are imported in a draft state so you must publish them to make them active.
- If a solution already exists in that environment, it must be deleted before it can be imported. You get a message if that is the case: "The solution is already installed on this system as an unmanaged solution and the package supplied is attempting to install it in managed mode. Import can only update solutions when the modes match. Uninstall the current solution and try again." To be clear, you can import a solution into another environment.
See more at How solutions are applied and at Import solutions.
When we import mysolution1_1_0_0_1_managed.zip into another environment, we are e.g. asked for values for all environment variables that have no default value set, and for connection references, if used. In our sample, that´s appsetting1.
When the import is completed, the content of the solution is existing in the new environment. We see the content of the managed solution (that cannot be modified): "You cannot directly edit the objects within a managed solution."
It can take some minutes, until the components are shown. here, we see the 2 apps imported...
...and the cloud flow:
When we edit the app or the flow, we need to create or to assign valid connections.
Power Apps also asks for connection when opening an app for the first time (which is also the "normal" behavior).
How to change the values of environment variables
Where did the environment variables go? Well, we can find them in the Dataverse / Tables. We need to switch to the All Tab, and here we can filter for "environment". This shows 2 tables:
The environment variables definitions are stored in the Environment Variable Definition Table, as we see. The tables usually show only a couple of columns. With the "+n rows" button, we can ass show additional metadata, like who created or modified the item, etc, as here.
When we look into the Environment Variable Value table, we see the value of our appsetting1 variable that we set at the import to "blue". We see that environment variables with a default value do not have a value set in this table, like our appsetting2.
So, this is where such resources and the content of an environment is stored: In the Dataverse tables of the environment.
Here, we can also modify the content. We can click on the Edit button, then click on the Edit row using form button, until we land in in an old-style Dynamics 365 form where the item (to "red") can be modified and saved.
This is how to change such values after the import.
Just to mention, we an also export items with their values. We then get a zip file, containing a csv with the table columns and the content for further processing. Also, Dataverse data can be exported to Azure Synapse to get insights over data in Dataverse as described here.
Import an unmanaged solution
Back to working with an unmanaged solution. The process for importing mysolution1_1_0_0_2.zip is the same as before, but we can modify all objects directly in the solution as well.
When the import is completed, we can modify resources in the unmanaged solution. For example, if we modify the Fruits App, and add a button to the canvas app, and publish the app, the deployed app will be updated from the solution. This works in the same way as in the original unmanaged solution.
We automatically get a new version that is set to Live, and the app contains the changes with the new button.
So, unmanaged solutions are best for development, while manages solutions should be the way how to deploy an application to another environment.
Update a solution
Updating a solution works the same as creating it. We update resources in the unmanaged solution. This causes an update of all published resources in the source environment. Then, we export the solution as managed solution.
In the target environment, we click on import solution as before.
When the solution import is completed, all resources in the environment are updated with the new version, depending on the action. See more at Upgrade or update a solution.
Solutions are an essential part of the deployment process in the Power Platform. Unfortunately, they cannot be used for all resources.
I hope this article provided some insight into how the Power Platform works and how to take advantage of the features that are available here.