Beware of Unmanaged Layers in Managed Solutions!

Unmanaged Layers in Managed Solutions

With Power Platform managed solutions, it’s easy to assume that all customisations remain neatly packaged and tightly controlled. This is not always the case!

Most components in managed solutions can be edited. This is true for apps, flows, tables, etc. The logic behind allowing this is that occasionally, a change may need to be made directly in a production environment. When this is done, the change takes effect immediately and the problem is addressed. However, this creates a new unmanaged layer in the edited component, that sits on top of all the managed layers.

Why is an Unmanaged Layer a Problem?

Although the unmanaged layer sits on top of the managed layers for the component, and exists inside the environment, it is outside the managed solution. For this reason, the unmanaged layer will always sit at the top of the stack, even if further managed solutions are installed. This means that while the unmanaged layer exists, the user will continue to see this customisation and not changes imported through managed solutions.

Unmanaged layers aren’t just created in apps, flows and tables, they can be created in most other components including environment variables and security roles.

If unmanaged layers are not addressed, they lead to ‘Environment Drift’ where environments that should behave identically, eg test and production, become inconsistent, making testing, bug fixing and support more difficult.

Making changes directly in a production environment is not recommended, but may be acceptable in certain circumstances. However, if you do this, you must replicate the change in the unmanaged development environment at the first opportunity. Then remove the managed layer you created in production and import the updated managed solution containing the changes made in development.

Unmanaged Layers can be Created Accidentally!

It’s important to know that you don’t need to deliberately edit a component in a managed solution to create an unmanaged layer. Simply clicking edit on a flow or other component in a managed solution can inadvertently introduce an unmanaged layer for that component. You don’t even have to make any changes or even click save for an unmanaged layer to sometimes be created!

I have been in this situation plenty of times. A flow fails, so you look at the flow run in a managed solution to see which action is at fault. You’ve no intention of editing the flow, but you absent-mindedly click edit to view the flow structure. It’s so easy to do! You realise what you’ve done and quit the edit flow mode. It doesn’t always create an unmanaged layer, but sometimes it does.

How to Tell if a Component has an Unmanaged Layer

Thankfully, it is easy to check if a component contains a managed layer.

Go to the managed solution, right-click on the component, and select ‘See solution layers’.

The solution layers will be displayed and any unmanaged layers will be displayed at the top of the stack.

Removing an Unmanaged Layer

It’s also straightforward to remove an unmanaged layer.

Right-click on the component and select ‘Remove active customisations’.

Alternatively, when viewing the component solution layers, select the unmanaged layer and click ‘Remove active customisations’ from the top menu.

Finding Components with Unmanaged Layers

It can be hugely time-consuming to manually check individual components to see if they contain an unmanaged layer. This becomes totally impractical if your solution contains hundreds of components!

However – there is a great solution to this, so read on!

The XRM Toolbox has a fantastic tool for identifying and addressing unmanaged layers. I really recommend it as one of my top three XRM Toolbox apps. It’s called Solution Layers Explorer.

Connect to your environment, open the XRM Toolbox and run Solution Layer Explorer. It has a simple and intuitive interface.

Select your solution from the left-hand menu. The list of component types for that solution will load. Select the component type you want to investigate, or select them all, and click ‘Load active Layers’. Bingo, all the components with an unmanaged layer are displayed!

If a component type has one or more managed layers, click on it to see the details, as I have done with Workflows (flows) to reveal the name of the flow with the unmanaged layer.

You now have 2 options.

The first is to go to your environment and inspect the component to see what managed layers exist. You can then delete them as described above.

The second option is to delete the managed components using Solution Layers Explorer. Select the particular component, component group, or all component groups and click ‘Remove Active Layers’; everything is done for you!

I recommend using Solution Layers Explorer regularly, and for large solutions, check it before you import a new managed solution. It can take a few minutes to run this check, but this could save you hours of frustration!

Best Practice

Always work from a development environment with an unmanaged version of the solution. Use Application Lifecycle Management (ALM) practices to manage changes systematically using managed solutions.
If possible, avoid editing or even viewing components in a managed solution.
If you have made an emergency change in a managed solution, make sure you make the equivalent change in your unmanaged development environment and delete the unmanaged layer in production before updating.
Regularly audit managed solutions for unmanaged layers using the Solution Layers Explorer tool in the XRM Toolbox. Remove them when found.
Get into the habit of running Solution Layers Explorer each time before importing a new managed solution to check that unmanaged layers haven’t been inadvertently created.