Solutions & Layers: ALM Foundations
Master Power Platform's solution system — the backbone of professional development. Learn managed vs unmanaged solutions, solution layering, dependencies, and environment variables.
Solutions: the container for everything
Think of a solution as a shipping container.
When you move house, you do not carry items one by one. You pack them into labelled boxes: “kitchen”, “bedroom”, “office”. Each box contains related items and has a list of what is inside.
A Power Platform solution is a container that holds your apps, flows, tables, plug-ins, connectors — everything that makes up your project. You build in a solution, export it as a file, and import it into another environment. No solution = no way to move your work from dev to production.
Managed vs unmanaged is the key distinction: unmanaged is your “working copy” (editable), managed is the “sealed package” (deployed, protected from changes).
Managed vs unmanaged solutions
| Feature | Unmanaged Solution | Managed Solution |
|---|---|---|
| Used in | Development environments | Test, UAT, and production environments |
| Components editable? | Yes — full edit access | No — locked, cannot be directly modified |
| Can be deleted? | Components remain in environment after solution delete | All components removed when solution is uninstalled |
| Upgrade path | No formal upgrade — just re-export | Supports staged upgrades with version numbers |
| Dependency tracking | Loose — easy to break dependencies accidentally | Strict — enforced at import time |
| Best practice | ONLY in dev environments | ALL non-dev environments (test, UAT, prod) |
The golden rule
Develop unmanaged → Export as managed → Import managed into production
Never import unmanaged solutions into production. If you do, components become part of the “unmanaged layer” and cannot be cleanly removed or upgraded. This is one of the most common mistakes tested on the exam.
Solution layering
When multiple solutions modify the same component, Dataverse uses layering to resolve which version wins.
Layer order (bottom to top):
- System — Base Dataverse components (Microsoft’s defaults)
- Managed solutions — In order of import (first imported = lowest layer)
- Unmanaged customisations — Always on top (highest priority)
The top layer wins. If two managed solutions both modify the same form, the one imported last takes priority. Unmanaged customisations always override everything.
Scenario: Elena debugs a form layout mystery
Elena Vasquez at Meridian Healthcare receives a complaint: “The Patient form used to show the Insurance section at the top, but now it’s at the bottom.”
She checks solution layers and finds:
- Base system — default form layout
- Claims Solution v1.0 (managed) — added Insurance section at the top
- HR Solution v2.0 (managed, imported after Claims) — reorganised the form, moving Insurance to the bottom
The fix: either update Claims Solution to v1.1 (reimport after HR Solution to take priority) or coordinate with the HR team to not modify the Patient form.
Exam lesson: When asked “why did a customisation disappear?”, check solution layers first.
Solution dependencies
Solutions can depend on components in other solutions. Dependencies must be managed carefully.
Types of dependencies:
- Required component — your solution uses a table or column defined in another solution
- Solution dependency — your solution explicitly requires another solution to be installed first
- Internal dependency — components within the same solution depend on each other
Managing dependencies:
- Run
pac solution checkbefore export to identify broken references - Use solution segmentation — include only the components you need, not entire tables
- Document dependencies in your solution’s description
- Import required solutions first, then dependent solutions
Environment variables
Environment variables store values that change between environments — URLs, feature flags, email addresses, thresholds.
| Variable Type | Example Use | Stored Value |
|---|---|---|
| Text | API endpoint URL | https://api.prod.example.com |
| Number | Approval threshold | 10000 |
| Yes/No | Feature flag | true |
| JSON | Complex configuration | Structured config object |
| Data source | Connection reference | Points to a specific connector |
| Secret | API key (stored in Azure Key Vault) | Key Vault reference |
How they work across environments:
- Definition travels with the solution (name, type, description)
- Current value is environment-specific (set during or after import)
- This separation means your solution works in any environment without hardcoded values
Exam tip: Environment variables vs hardcoded values
If an exam question mentions values that differ between dev, test, and production (API URLs, email addresses, thresholds), the answer is almost always environment variables. Hardcoded values in flows, apps, or code create deployment failures when moving between environments.
The secret type is especially important — it stores sensitive values like API keys in Azure Key Vault, not in the solution itself.
Elena imports two managed solutions into the production environment: Solution A (version 1.0, contains a modified Contact form) and then Solution B (version 2.0, also modifies the Contact form). A maker then manually edits the Contact form in the unmanaged layer. Which version of the Contact form is displayed to users?
A developer needs to configure a cloud flow that sends error alerts to different email addresses in dev (developer@company.com), test (qa-team@company.com), and production (ops-team@company.com). How should the email address be stored?
🎬 Video coming soon
Next up: CI/CD Pipelines for Power Platform — automating deployments with Power Platform Pipelines and Build Tools.