Solution Layering in Power Apps – The Hidden pitfalls of deployments
Issue
Have you ever deployed a solution to your test or production environment and found that your changes aren’t visible? There can be multiple problems causing this issue.
Today, we are going to focus on one of the most common scenarios: an active unmanaged layer.
If not properly addressed, this can lead to conflicts, version control issues, and an overall loss of development consistency across environments.
Deployments and solutions
In Power Apps, a solution is a container that holds a set of components customized in the system, such as entities, plugins, flows, etc.
While working in a development environment, we package components into unmanaged solutions. Depending on the project, there might be one or multiple solutions.
Later, those solutions are exported as managed ones and imported into higher environments.
But what is the difference between an unmanaged and a managed solution?
An unmanaged solution is an editable version of the solution, where you can modify components directly within the solution without restrictions. A managed solution, however, cannot be edited directly, which makes it easier to control and track changes. That’s why it is recommended to use managed solutions for purposes other than development.
Let’s say we created a component and deployed the changes to the test environment. The picture below shows how solutions (layers) are applied in the destination environment.
As you can see, at the bottom, we have a managed layer. There can be multiple managed layers, depending on how many solutions modify a particular element. Managed layers are created in the order in which solutions are imported.
Above the entire managed layer, we have an unmanaged one. This is what the user sees. More about layers can be found here.
As mentioned, unmanaged customizations are at the top and, in fact, they define the runtime behavior of the component—they determine how the component behaves. In most cases, we don’t want such unmanaged changes in environments like test or production.
The question is, how might such an unmanaged layer have been created?
Usually, such changes result from one of the following:
- Changes made directly in the environment—such as a developer wanting to immediately fix an issue in the production environment.
- Someone simply made a mistake and selected the wrong environment in the Maker portal.
- Someone imported unmanaged solutions.
Later, when the DevOps team upgrades managed solutions, some of these changes might not be visible due to the unmanaged layer. It is due to the fact that active unmanaged layer is always the top layer and overwrites everything in managed solutions.
There are also cases when the creation of an unmanaged layer cannot be avoided. For example, when you need to change the seed of an auto-number field, you must modify it directly in the desired environment (currently, the seed is not a solution component).
Tools
How can we identify such issues before they happen? Let’s explore some tools that can help you recognize potential problems with active unmanaged layers.
Maker portal
The first one can be found in the Maker portal. After you log in to the portal open the Solution Explorer. In the explorer, there is a useful feature, where, for each component in the advanced settings, you can visualize the current layers.
This tool allows you to check what each layer modifies, and if you choose to, you can remove the active unmanaged layer by simply selecting it and clicking ‘Remove active customizations.’
You can find more information here.
Solution Layer Removal (XrmToolBox)
This extension allows the user to check which components, and of what type, were modified within a specific solution. Then, for each component, a user can decide to remove that layer.
Solution Layer Explorer (XrmToolBox)
The following XrmToolBox plugin can list all active layers for selected solutions. You can then select specific components and remove unwanted modifications.
Unmanaged Active Layer Bulk Remover (XrmToolBox)
This tool removes active unmanaged layers in bulk for selected solutions and solution components. Before using it, I would recommend checking exactly what was modified and why.
Summary
To summarize, let’s list the most crucial information and basic tips you can follow to avoid such issues:
- Active unmanaged layer stays always on top and overwrites any other managed changes.
- Always try to deploy changes as managed solutions.
- Avoid applying hotfixes as customizations made directly in production environments.
- If you can’t avoid such changes, keep track of them, reapply them in the development environment, and after a managed solution is upgraded in production, remove unnecessary layers.
- Plan updates carefully—it’s a good idea to have separate hotfix/warmfix environments where you can create fixing solutions.
- Use version control (like Git) to keep track of changes in your solutions.
- Make sure to oversee who can make changes in higher environments by using security roles.
- Test layering in test or pre-production environments.
In the next post, we will discuss more issues related to solutions and merging managed layers.