If you work with Power Platform or Dynamics 365, understanding Application Lifecycle Management (ALM) and solution layering is not optional. It is one of the core areas that determines whether your deployments remain predictable and maintainable, or gradually become difficult to support.
A lot of platform issues that appear “random” are often not random at all. They usually come down to one of the following:
- unmanaged changes made directly in an environment,
- unexpected managed solution overrides,
- patches or upgrades applied without understanding the current layer stack,
- or poor separation between development and deployed customisations.
What ALM means in Power Platform
ALM is the process of managing how solutions are:
- designed,
- developed,
- tested,
- deployed,
- versioned,
- and maintained across environments.
In Power Platform, that usually means moving changes through environments such as:
- Development
- Test / UAT
- Pre-Production
- Production
Done well, ALM gives you:
- repeatable deployments,
- safer releases,
- clearer ownership of customisations,
- easier rollback and troubleshooting,
- and better collaboration across teams.
Done badly, it creates fragile environments where no one is fully sure which version of a component is actually running.
What solution layering is
Every component in Dataverse — such as a table, column, form, view, app, workflow, or command bar customisation — can have multiple layers applied to it.
You can think of solution layering as a stack of customisations. The platform evaluates that stack to determine the final effective version of the component.
Typical layers may include:
- the system layer,
- managed solution layers from installed solutions,
- patches and upgrades,
- and finally active unmanaged customisations.
This is important because the behaviour you see in an environment is not always explained by the last change you personally made. It may be the result of how several layers combine.
Unmanaged solutions
An unmanaged solution is primarily for development.
It is editable in the environment where it exists, and the changes become part of that environment’s active customisation layer.
Why unmanaged solutions are useful
- They are ideal for building and iterating in development.
- They make it easy to add and modify components quickly.
- They are the normal container used while actively creating a solution.
The risk with unmanaged solutions
The problem is that unmanaged changes are easy to make directly in an environment, especially if multiple people have elevated access.
That can lead to:
- drift between environments,
- undocumented hotfixes,
- difficulty reproducing production behaviour in lower environments,
- deployment conflicts later,
- dependency issues that block releases,
- and longer deployment times while teams try to resolve unexpected layer problems.
As a rule, unmanaged layers should be avoided in production. The main exception is a genuinely time-critical production issue where a temporary change is needed to stabilise the system before the proper fix can move through the normal deployment pipeline and approval stages.
Even then, that should be treated as a short-term emergency measure only. The change should be documented, replaced by a proper managed deployment as soon as possible, and removed from the active unmanaged layer so production returns to a controlled state.
If production contains direct unmanaged edits, your source-controlled solution may no longer represent reality.
Managed solutions
A managed solution is intended for deployment into downstream environments such as test or production.
Unlike unmanaged solutions, managed solutions are designed to behave more like installed application packages.
Why managed solutions matter
- They enforce stronger deployment discipline.
- They reduce the temptation to edit production directly.
- They make solution ownership and upgrade paths clearer.
- They support healthier enterprise ALM practices.
In most mature delivery setups, development happens in unmanaged form, but releases to higher environments happen as managed deployments.
Why understanding the difference matters
The distinction between unmanaged and managed solutions is not just academic.
It directly affects:
- how changes are introduced,
- how issues are diagnosed,
- how upgrades behave,
- and how confidently teams can release.
For example:
- If a production issue only exists in one environment, check whether unmanaged customisations were applied directly.
- If a form or command bar is not behaving as expected after deployment, inspect the layer stack.
- If a managed update appears to do nothing, an unmanaged top layer may be overriding it.
Without understanding layering, teams often misdiagnose root causes and waste time fixing the wrong thing.
A practical mental model
A useful way to think about it is this:
- Unmanaged = your editable working state
- Managed = your deployed package state
- Layers = the rule set that determines what actually wins
If you understand those three ideas, you can usually reason through most environment-specific behaviour in Power Platform.
Common anti-patterns
Here are some of the most common mistakes I see:
1. Editing production directly
This is the fastest way to lose confidence in your deployment process. Even when done with good intentions, it creates drift and makes future releases riskier.
2. Treating solutions like simple folders
A solution is not just a convenient export container. It is part of a layered application model. The order and type of deployments matter.
3. Ignoring the solution layers view
The layers view is often one of the most valuable troubleshooting tools in the platform. If something looks wrong, inspect the layers before assuming the deployment failed.
4. Mixing temporary fixes with long-term releases
Quick fixes made outside the normal release flow often become the source of larger problems later, particularly when a later managed deployment appears to “undo” or fail to reflect a change.
Recommended approach
A healthy Power Platform ALM approach usually includes:
- Building changes in a dedicated development environment.
- Keeping the source of truth in source control.
- Using unmanaged solutions for active development.
- Deploying managed solutions to downstream environments.
- Restricting direct production customisation.
- Reviewing solution layers when troubleshooting unexpected behaviour.
- Having a clear versioning and release process.
Azure Pipelines and controlled releases
Azure Pipelines can be used effectively to deploy solutions through multiple environments, with each environment represented as a separate stage in the release flow.
That approach is useful because stages can be approval-gated, helping enforce a consistent release pattern such as:
- Development
- Test / UAT
- Pre-Production
- Production
This gives teams stronger control over how fixes and features move through the estate, and reduces the temptation to bypass agreed deployment practices.
Pipelines can also use scripts to handle environment-specific configuration, including tasks such as setting or updating environment variables as part of the deployment process. That becomes especially valuable when you want deployments to remain repeatable and avoid manual post-deployment steps.
Final thoughts
ALM and solution layering are not just platform theory — they are essential practical knowledge for anyone building serious Power Platform solutions.
If you understand how unmanaged and managed solutions behave, and how layers affect the final state of a component, you will make better architectural decisions, troubleshoot faster, and avoid many of the issues that commonly affect enterprise environments.
In short: if you want predictable deployments, stable environments, and fewer surprises, learn solution layering properly. It is one of the most valuable investments you can make as a Power Platform developer and is an important piece that I consider to be fundamental.