Crm Minds

Hey everyone,

Today I want to talk about something that has saved me countless hours of troubleshooting over the years. If you are working with Dynamics 365 or PowerApps and managing multiple environments, this is going to be important for you.

Have you ever deployed a solution to TEST or PROD and then found out that things behave differently than they did in DEV? Or worse, someone reports a bug that you simply cannot reproduce in your development environment? There is a good chance you are dealing with unmanaged layers.

What Are Unmanaged Layers and Why Do They Matter?

Let me set the context first. In Dynamics 365, when you make changes to components like forms, views, or business rules, those changes can exist as either managed or unmanaged customizations. In a healthy ALM process, your DEV environment has unmanaged changes (because you are actively developing), and your higher environments (TEST, UAT, PROD) should only have managed solutions.

But here is the problem. Anyone with the right permissions can make changes directly in any environment. When someone makes a change directly in TEST or PROD, it creates an unmanaged layer. This unmanaged layer sits on top of your managed solution and overrides it. Silently.

The Risks of Unmanaged Layers in Higher Environments

Let me break down why this is a big problem.

1. Overriding Your Managed Solutions

Your managed solutions contain the official, tested, source-controlled version of your customizations. When an unmanaged layer exists, it wins. Always. Your carefully tested deployment gets overridden by someone’s quick fix that never went through proper testing or code review.

2: Troubleshooting Nightmares

You look at your solution in source control. You check the managed solution in the environment. Everything looks correct. But the system behaves differently. Hours later, you discover there is an unmanaged layer hiding in there, changing things behind the scenes.

3: Your ALM Process Breaks Down

Your entire deployment pipeline assumes that what you deploy is what runs. When unmanaged layers exist in higher environments, that assumption is broken. You lose confidence in your deployments.

4: Audit and Compliance Issues

Changes made directly in an environment are not tracked in source control. You have no audit trail. For regulated industries, this can be a serious compliance issue.

How to Check for Unmanaged Layers

Here is how you can check for unmanaged layers in your environment.

Using the UI

1. Navigate to make.powerapps.com
2. Go to Solutions
3. Select “See solution layers” on any component
4. Look for layers marked as “Unmanaged”

This works fine for checking individual components, but what if you want to check everything?

Using PowerShell

Here is a PowerShell script that connects to your environment and identifies all components with unmanaged layers. This uses the Microsoft.Xrm.Data.PowerShell module.

# Install the module if you don't have it
# Install-Module Microsoft.Xrm.Data.PowerShell -Scope CurrentUser
# Connect to your environment
$conn = Get-CrmConnection -InteractiveMode
# Query for solution components with unmanaged layers
$fetchXml = @"
<fetch>
  <entity name='solutioncomponent'>
    <attribute name='objectid' />
    <attribute name='componenttype' />
    <link-entity name='entity' from='objectid' to='objectid' link-type='outer' alias='unmanagedlayer'>
      <filter>
        <condition attribute='ismanaged' operator='eq' value='0' />
      </filter>
    </link-entity>
  </entity>
</fetch>
"@
$result = Get-CrmRecordsByFetch -conn $conn -Fetch $fetchXml
# Display results
if ($result.CrmRecords.Count -gt 0) {
    Write-Host "Found $($result.CrmRecords.Count) components with potential unmanaged layers" -ForegroundColor Yellow
    foreach ($record in $result.CrmRecords) {
        $componentType = $record.componenttype
        $objectId = $record.objectid
        Write-Host "Component Type: $componentType, Object ID: $objectId"
    }
} else {
    Write-Host "No unmanaged layers found. Environment is clean!" -ForegroundColor Green
}

This script gives you a quick overview. You can also use the Power Platform CLI or the API directly if you want to build more sophisticated checking tools.

What to Do When You Find Unmanaged Layers

When you find unmanaged customizations in higher environments, here is what you should do:

1. Document the changes – Before removing them, understand what they do. Someone might have had a good reason.
2. Decide if you need them – If the change is valid, bring it back to DEV and go through proper ALM.
3. Remove the layer – You can remove unmanaged layers through the UI.
4. Investigate how it happened – Figure out who made the change and why, so you can prevent it in the future.

Best Practices to Prevent This

Here are some practices that have worked well for me and my clients:

1. Never customize directly in TEST, UAT, or PROD – This should be a hard rule. All changes go through DEV first.
2. Restrict permissions – Limit who can create or modify unmanaged customizations in higher environments.
3. Regular audits – Check for unmanaged layers weekly in TEST, monthly in UAT and PROD.
4. Educate your team – Make sure everyone understands why this matters.
5. Automate the check – Add a script to your CI/CD pipeline that checks for unmanaged layers and alerts you.

Wrapping Up

Unmanaged layers in higher environments are like hidden bugs waiting to happen. They break your ALM process, make troubleshooting difficult, and create compliance issues. The good news is that checking for them is straightforward, and preventing them is mostly about process and permissions.

I recommend you check your TEST, UAT, and PROD environments today. You might be surprised what you find. And if you find something, take the time to clean it up and put processes in place to prevent it from happening again.

Clean environments lead to predictable deployments. And predictable deployments make everyone’s life easier.

Until next time, happy deploying!