Solution dependencies and managed layer conflicts

Power Platform solutions don't live in isolation. They reference Microsoft's standard components, ISV components from AppSource, and components from other internal solutions. Understanding dependencies and managed layers is essential for clean deployment, predictable behaviour, and successful upgrades.

Component dependencies.

A solution component depends on others when it references them:

• A flow depends on Dataverse tables it reads or writes.
• A canvas app depends on connection references it uses and tables it references.
• A business rule depends on the fields it references.
• A report depends on the tables and views it queries.
• A plug-in depends on the assemblies, tables, and other plug-ins it interacts with.

When a solution is exported, dependencies are tracked. When the solution is imported into a target environment, all dependencies must be present — either in the target already, or imported as separate solutions first.

Tracking dependencies.

The maker portal's Dependencies view on each solution and each component shows:

• Components that depend on this — who's pointing at me.
• Components I depend on — what I need to function.

Before deleting a component, check who depends on it. Removing a field that 50 flows reference breaks all 50.

Solution dependency chain. Solution A depends on Solution B (e.g. Customer Service Customisations depends on the Microsoft Customer Service base solution). Imports must happen in order:

1. Microsoft base solution (Customer Service) — already in the environment from Dynamics 365 install.
2. ISV solution from AppSource (industry vertical for service).
3. Customer-customisation solution layered on top.

The target environment must have all parent solutions before child solutions can import.

Managed layers.

When multiple solutions modify the same component, they stack as layers:

• Layer 0: System defaults — the original definition shipped by the platform.
• Layer 1+: Each managed solution that touches the component adds a layer.
• Top layer: Unmanaged customisations in the dev environment.

The component's effective behaviour is determined by the topmost active layer. Underlying layers are hidden but preserved; if a top layer is removed (solution uninstall), the next layer down takes effect.

The Solution Layers view on each component lists the layers stacked there, with the source solution for each.

Conflicts and resolution.

When multiple managed solutions modify the same component (e.g. two AppSource ISV solutions both adding columns to the Account table), the system stacks both layers; runtime behaviour combines both modifications.

For more substantive conflicts (two solutions defining the same workflow on the Account, two solutions changing the same field's display name):

• The last imported wins typically.
• But the system tries to preserve all modifications, which can produce surprising layered effects.
• Conflicts are visible in the Solution Layers view.

Resolving conflicts is manual — remove one layer's modification or merge intent into one solution.

Common patterns.

• Microsoft base + AppSource ISV + customer customisation. Three layers, in that order. The customer-customisation solution depends on the ISV depends on the Microsoft base.

• Multiple customer solutions for separate features. A Sales Customisations solution, a Service Customisations solution, a Reporting solution. Each has its own scope; minimal overlap. Clean dependency graph.

• One-big-solution anti-pattern. A single huge customer solution containing everything. Simpler to deploy but harder to reason about, slower to import, harder to retire individual features.

Uninstalling solutions.

Uninstalling a managed solution removes its layer. The underlying state takes effect again. But:

• Data is not removed — records that depend on the solution's tables remain.
• Dependencies must be checked — if other solutions depend on this one, uninstall is blocked.
• Order matters — uninstall top-most solutions before underlying ones.

Common pitfalls.

• Circular dependencies — solution A depends on B and B depends on A. The system rejects this; resolve by separating shared components into a third solution.
• Missing dependency on import — solution import fails because a required parent isn't in the target. Import the parent first.
• Orphan layers after uninstall — the layer is removed, but the data referencing the removed components becomes orphan. Data cleanup may be needed.
• Solution gigantism — solutions grow to encompass everything; imports take hours; reasoning is impossible. Split.

Operational discipline.

• Map your solution dependency graph — document which solutions depend on which.
• Plan release order — when releasing multiple solutions together, plan import order.
• Audit layers periodically — accumulated layers from old solutions clog environments.
• Refactor solutions when their scope grows unmanageable.

Healthy solution architecture pays back over years of operation.