2.3 Solutions, Managing Dependencies & Solution Layers
Key Takeaways
- Every solution has a publisher-defined customization prefix stamped onto the schema name of new components created inside it.
- Unmanaged solutions are for active development; managed solutions, exported just before deployment, are the only type that should reach production.
- The maker portal's Show Dependencies view lists everything a component requires and everything that depends on it before you delete or remove it.
- The unmanaged layer is always the topmost layer in an environment, overriding every managed layer beneath it regardless of import order.
- Patches capture a small delta without re-exporting a full solution; cloning later merges patches back into one new full version.
Solutions, Managing Dependencies & Solution Layers
Quick Answer: A solution packages customizations for ALM. Developers author in unmanaged solutions in a development environment, then export as managed for deployment to test and production. Dataverse tracks component dependencies automatically and stacks each managed import as a solution layer, with the unmanaged layer always sitting on top.
Solutions as the Unit of ALM
A solution is the container that packages the customizations a maker or developer builds - tables, columns, forms, views, plug-in assemblies and steps, cloud flows, connection references, environment variables, web resources, and PCF components - so they can move between environments as a single, versioned unit. Every solution has a publisher, and every publisher defines a customization prefix (for example, contoso_) that is stamped onto the schema name of every new component created inside that publisher's solutions, such as contoso_projectstatus. Using one consistent publisher and prefix per organization, rather than the default prefix, avoids naming collisions when multiple teams or ISV solutions land in the same environment.
Managed vs. Unmanaged
| Unmanaged | Managed | |
|---|---|---|
| Editable after import? | Yes, freely | No - locked, unless the publisher marked specific properties customizable |
| Typical use | Active development, source of truth | Deployment package for test/production |
| Can be uninstalled cleanly? | No - components remain and become unmanaged | Yes - uninstalling removes everything the solution added |
| Where authored? | Development environment | Exported as managed from the dev environment right before deployment |
Developers build and iterate in an unmanaged solution in a development environment. When it's time to ship, that solution is exported as managed and imported into test and production - never edited by hand in a downstream environment. This is the core discipline PL-400 tests: unmanaged solutions are for authoring, managed solutions are for deploying.
Managing Dependencies
Every component added to a solution can depend on other components: a form depends on the columns it displays, a plug-in step depends on the message and table it's registered against, a flow depends on a connection reference and the tables its Dataverse trigger watches. Dataverse tracks these relationships automatically.
- "Show Dependencies" on any solution component lists everything it requires and everything that requires it, before you delete or remove it.
- Missing-dependency errors on import happen when a solution references a component - a table, a choice, another solution's plug-in assembly - that doesn't exist yet in the target environment. The fix is either to add the missing component to the solution or to import a prerequisite solution first, in the correct order.
- "Add Required Components" in the maker portal automatically pulls in everything a selected component depends on, which prevents accidentally shipping a form without the column it references.
- Deleting a component that other unmanaged customizations still depend on is blocked; deleting one that a managed solution depends on can break that managed solution on its next update.
Solution Layering
When more than one managed solution customizes the same component - for example, two ISV solutions both add a form to the Account table, or a hotfix solution updates a column already shipped by the base solution - Dataverse stacks each import as a layer. Layer order matters:
- Layers stack in import order by default; the most recently imported managed solution's changes to a component sit on top and are what users see, unless the layer order is deliberately changed.
- The unmanaged layer is always the topmost layer in every environment, regardless of how many managed layers exist below it. Any unmanaged customization overrides every managed layer, which is exactly why production environments should have no meaningful unmanaged layer at all.
- The maker portal's "Solution Layers" view, available per component, lets you inspect every layer, see which one is currently "winning," and - for advanced remediation - change the active layer order without re-importing anything.
- Patches and clones: rather than re-exporting an entire solution for a small fix, a developer can create a patch (a small solution capturing only the delta) or later clone the solution, merging all patches back into a new full version, to keep the deployment package clean over time.
Exam Angle
PL-400 questions in this area typically present a "component X isn't behaving as expected after two solutions were imported" scenario and ask which concept explains it - dependency tracking, layer order, or the always-on-top unmanaged layer - or ask what pre-flight check, such as Show Dependencies, would have caught the problem before deployment.
Two managed solutions both customize the same form on the Account table, and a developer also made an unmanaged change to that form directly in production. Which version of the form do users see?
Before deleting a column from an unmanaged solution, a developer wants to confirm nothing else in the environment relies on it. Which feature should they check first?