Power Platform ALM with managed solutions

Application lifecycle management (ALM) is what turns one-off Power Platform experiments into a maintainable system. Microsoft's ALM story is centred on solutions — versioned, deployable containers of components — moving through a chain of environments with controlled promotion.

Solutions

A solution is a Dataverse-aware bundle of customisations: tables, columns, forms, views, charts, web resources, Power Automate flows, canvas apps, model-driven apps, business process flows, security roles, and many more. A solution has a publisher (with a prefix that scopes custom names) and a version number.

Unmanaged vs managed

Solutions exist in two states:

• Unmanaged — editable. Components inside an unmanaged solution can be modified in the environment they live in. The state of every dev environment.
• Managed — read-only at the component level. Imports of managed solutions install or update components without letting downstream users edit them. The state of every UAT and production environment.

The flow

Develop in an unmanaged solution in a dev environment. Export the solution as managed. Import the managed solution to UAT. Test. Import the same managed package to production. Repeat per release.

Environments

A healthy Power Platform deployment uses at least three environments: Dev, Test/UAT, Production. Larger organisations add per-feature dev environments, hotfix environments, and training environments. Each environment is administered through the Power Platform admin centre.

Pipelines

Power Platform pipelines is Microsoft's built-in promotion mechanism: configure a pipeline from dev → UAT → prod, with approvals and validation gates, and run promotions from the maker portal. For more complex needs, Azure DevOps or GitHub Actions with the Power Platform build tools automate end-to-end CI/CD: export solution on commit, build, validate, deploy.

Source control

Solutions can be unpacked with the pac CLI into a folder of XML and YAML files — one file per table, form, flow, app — that lives in Git. Pull requests review the diff, branches isolate features, and pipelines build and deploy on merge. This is the canonical way to manage non-trivial Power Platform development.

Solution layering

Multiple solutions can install on top of each other (e.g. ISV base + customer customisations). Layering is helpful for ISV scenarios; for in-house teams it complicates things — start with one solution per logical app.

Anti-patterns

Editing directly in production. Building in the default environment. Having no version control. All trade speed today for pain forever; resist them from day one.

Where to go next

Next: solution patches vs upgrades for the release rhythm, connection references and environment variables for environment-specific configuration — with connection references best practices and environment variables, in depth going further on each — import and export pipelines and ALM with GitHub Actions for automation. When an import fails, solution import errors is the reference.