Dynamics 365 — how solution layering can help you resolve solution updating problems

A problem clearly stated is a problem half solved. Dorothea Brande

I was importing a managed solution into my test environment, only to find it wasn’t updating the Canvas App. There can be many reasons for solutions not updating and this post will discuss the cause and the solution.

Environment setup

Below are the environments we use.

Dev → Dev Master → QA/UAT/Training

Developers make changes in the Dev environment and creates a patch, deploys to Dev master. Dev Master is the environment is used to create our managed solution, which is imported into the non development environments. It’s managed because no one should change customisations outside of the Dev environment, this helps to control the environments and keep them all in Sync.

Once your environments are out of sync your testing becomes unreliable because you can’t be sure what customisations are triggering and working to in the whole solution.

The problem

A model driven app was updated, adding more views to an entity but when deployed to the QA environment the new views were not showing.

  • Dev + Dev Master — 10 views
  • QA — 3 views

What was causing QA to only show 3 views?

I wanted to confirm the changes had been checked into source control and the AppModule.xml had been updated.

The solution packager breaks down all the customisations in your solution into xml files. This is great for checking into source control and managing your customisations. Below are the folders it creates.

In the AppModules folder, I found these

I found the entity I had changed (no it’s not really called HoskEntity)

<AppModuleComponent type="1" schemaName="HoskEntity" /><AppModuleComponent type="26" id="{aba4dde6-7a10-ea11-a811-000d3a4ab96a}" />
<AppModuleComponent type="26" id="{b174159f-04b9-e911-a82e-000d3a47cb1d}" />
<AppModuleComponent type="26" id="{2fe72247-43b9-e911-a82e-000d3a47cb1d}" />
<AppModuleComponent type="26" id="{b3589b99-42b9-e911-a82e-000d3a47cb1d}" />
<AppModuleComponent type="26" id="{001594bd-43b9-e911-a82e-000d3a47cb1d}" />
<AppModuleComponent type="26" id="{7bd435d8-43b9-e911-a82e-000d3a47cb1d}" />
<AppModuleComponent type="26" id="{3a2bdec8-7a10-ea11-a811-000d3a4ab96a}" />
<AppModuleComponent type="26" id="{19a41b6a-43b9-e911-a82e-000d3a47cb1d}" />
<AppModuleComponent type="26" id="{1670e091-43b9-e911-a82e-000d3a47cb1d}" />
<AppModuleComponent type="26" id="{ffa5f67d-43b9-e911-a82e-000d3a47cb1d}" />

If you can’t read Dynamics xml, this page AppModuleComponent helps

  • Type 1 = Entities
  • Type 26 = Views

My entity has 10 views, which is what I expected and confirmed the problem isn’t here. Bug fixing isn’t about finding the problem straight away, every assumption you clarify takes you closer to the cause of the problem.

QA Environment

In the QA environment to the model driven app and pressed the solution layering button. This is a useful tool enabling you to see what customisations are layered on top of each other. Different customisations in different orders can produce different results.

Solution layering button has two other useful features.

you can click on the layer and see the customisations

There is a button which allow you to remove those customisations (if you click the three dots).

Read these articles to learn more

The customisations on the default layer, show the xml of the AppModule. I searched for the entity I had changed and found it only had three views.

<AppModuleComponent type=”1" schemaName=”HoskEntity” />
<AppModuleComponent type=”26" id=”{b174159f-04b9-e911-a82e-000d3a47cb1d}” />
<AppModuleComponent type=”26" id=”{2fe72247–43b9-e911-a82e-000d3a47cb1d}” />
<AppModuleComponent type=”26" id=”{b3589b99–42b9-e911-a82e-000d3a47cb1d}” />

The manual layer was the highest layer and above of the managed layer. This is a common scenario that unmanaged changes can block/freeze and stop managed changes.

Repeat the Mantra

Only changes customisations in DEV

Out of sync environments hide bugs which then appear in production. The testing you do in an environment that isn’t the same as production is not as useful for predicting how production will work.


To resolve the problem I removed the unmanaged layer which was the layer above my managed solution. When I removed the unmanaged layer, the managed solution then popped to the top I then saw the 10 views I was expecting.

In this case I knew there shouldn’t have been an unmanaged solution because no one should be making changes in QA, any changes to customisations should happen in DEV and be pushed through to QA.

Unmanaged changes in an environment are a common cause of customisations not updating and the solution layer button is good method for finding these.

Related articles on bug fixing