Introduction
Dataverse uses a layered model for customizations. When multiple solutions modify the same component, layers stack up — and conflicts can appear. Understanding this model is critical for CE consultants working with multiple environments and teams.
How Layers Work
Every customization (entity, form, plugin, etc.) has a layer stack. The order of layers, from bottom to top:
- System — Microsoft’s base definitions
- Managed solutions — Installed managed solutions, oldest first
- Unmanaged solutions — Your unmanaged customizations
When you install Solution B on top of Solution A, B’s layer sits above A’s. The topmost layer wins for each attribute or setting.
Unmanaged vs Managed
- Unmanaged — You can edit components directly; layers are editable
- Managed — Components are locked; you can only add new layers on top
In development, you work in unmanaged solutions. For deployment to UAT/Production, you typically export as managed so recipients can’t accidentally change your customizations.
When Conflicts Happen
A conflict occurs when:
- Two solutions in the same layer type (e.g., both unmanaged) modify the same component
- A lower layer has a value that a higher layer tries to remove or override in an incompatible way
Common conflict sources:
- Two developers editing the same entity in different solutions
- Applying an upgrade that changes the same form/field as a local customization
- Merging branches that both add/modify the same components
Avoiding Conflicts
1. One Solution Per Environment (When Possible)
Use a single unmanaged solution per environment for your customizations. Avoid having Dev1_Solution and Dev2_Solution both modifying the same entities.
2. Use a Single Development Solution
All developers contribute to one solution. Use source control and branching for code, but keep the solution structure consistent.
3. Publish Before Export
Always Publish All Customizations before exporting. Unpublished changes can cause unexpected behavior and phantom conflicts.
4. Check Dependencies
Before removing a component, check dependencies. Removing a field that’s used in a form or flow will cause issues — and sometimes conflicts.
5. Use Patch Solutions for Minor Updates
For small updates to an existing managed solution, use a patch (e.g., MySolution_1_0_0_1) instead of a full new version. Patches sit on top of the base solution and reduce merge complexity.
Resolving Conflicts
When a conflict appears during import:
- Review the conflict report — Dataverse shows which components conflict and what the differences are
- Choose a resolution — Typically: keep your version, accept theirs, or merge manually
- For unmanaged — You can often edit the conflicting component directly and remove the conflicting layer
- For managed — You may need to uninstall and reinstall, or use a patch to override
If you’re unsure, export a backup of the target environment before resolving.
Layer Order and Precedence
The layer order determines precedence. If Solution A (installed first) and Solution B (installed second) both change a form:
- B’s changes appear in the UI
- A’s layer still exists underneath
- Uninstalling B would reveal A’s version again
This is why upgrade order matters when applying multiple solutions.
Best Practices Summary
- Use one main unmanaged solution for development
- Publish before every export
- Use managed solutions for deployment
- Use patches for incremental updates
- Document solution dependencies and installation order
- Avoid editing the same components in parallel solutions
Summary
Solution layers are central to how Dataverse manages customizations across solutions and environments. Design your solution strategy early, stick to a single development solution when possible, and always publish before export. When conflicts arise, use the conflict report to understand what’s overlapping and resolve deliberately.