3.2 Solution and Application Lifecycle Management Strategy

Solutions: The Unit of ALM

In Microsoft Power Platform, a solution is the container that groups every component of an intelligent application — apps, flows, agents, Dataverse tables, choices, security roles, and more — so it can be transported between environments. Application lifecycle management (ALM) on the AB-410 exam is, at its core, the discipline of moving solutions through DEV, TEST, and PROD in a controlled way.

Solutions exist in two states:

• Unmanaged — fully editable; used in the development environment where you are actively building. Deleting an unmanaged solution removes only the container, not the components inside it.
• Managed — locked and read-only; imported into TEST and PROD. Components in a managed solution cannot be edited directly, and deleting a managed solution uninstalls it, removing all of its components. That clean install and uninstall behavior is exactly why managed is mandatory downstream.

Golden rule for the exam: develop as unmanaged, deploy as managed.

Publishers and the Customization Prefix

Every solution references a publisher, and every publisher defines a customization prefix that is prepended to the schema name of every new component — new_ for the out-of-box default publisher. Before any real development, create a publisher for your organization (for example, Contoso Ltd with prefix cts), so components are named cts_expensereport instead of new_expensereport. Use one publisher consistently across all of your organization's solutions so dependencies and layering stay predictable.

Segmenting Solutions and Patching

Large intelligent applications are rarely a single solution. Common patterns include a base solution holding shared tables and core components plus extension solutions that depend on it, and a segmented approach where each solution contains only the components you actually change, keeping imports fast and merges clean.

For hotfixes, create a solution patch from the parent solution in make.powerapps.com (Solutions, open the solution menu, then Clone > Clone a patch). A patch can only add or modify components of its parent — it cannot remove components — and it increments the build or revision segment of the version number, which follows the format major.minor.build.revision. When the next full release is ready, clone the solution to roll the patch back into the parent and advance the major or minor version.

Environment Variables and Connection References

Two solution components exist specifically to make imports portable:

• Environment variables hold configuration values such as SharePoint site URLs, mailbox addresses, or feature flags. The solution stores the definition; each target environment supplies its own current value, and the import wizard prompts for any value that is missing. Apps and flows read the value at runtime, so the same managed solution behaves correctly in DEV, TEST, and PROD without edits.
• Connection references decouple flows and apps from specific connections. The solution references a logical connection; the person importing wires each reference to a real connection in the target environment.

Exam trap: hardcoding URLs or connections inside components forces unmanaged edits downstream — the exam-correct answer is almost always environment variables plus connection references.

Power Platform Pipelines vs Manual Export and Import

Manual export and import from the Solutions area of make.powerapps.com works for simple, occasional deployments — export a managed file from DEV, import it into TEST. But Pipelines in Power Platform is the built-in ALM service the exam prefers for repeatable deployments:

• An admin installs the pipeline experience in a dedicated host environment and configures it through the Deployment Pipeline Configuration app.
• A pipeline defines stages (for example, Test and Production), each bound to a target environment; deploying from the development environment pushes the solution through the stages in order.
• Pre-deployment step approvals let a designated approver review and approve before a solution reaches production, creating an auditable gate without Azure DevOps.
• Deployments can run under a service principal (delegated deployment), and every run is recorded in deployment history with notes and validation results.

Pipelines is a managed environments feature — remember the licensing implication from section 3.1.

Layering, Update vs Upgrade, and Dependencies

Dataverse applies customizations in layers: the system layer at the bottom, then managed solutions in install order, then the unmanaged layer on top. The unmanaged layer always wins — which is why an unmanaged tweak in TEST can silently mask managed updates, and why TEST and PROD must stay clean of unmanaged changes.

When importing a managed solution that already exists in the target, you choose how to apply it. An update merges the new version but leaves behind components that were removed from the solution. An upgrade — available as the two-step stage for upgrade followed by apply upgrade — fully replaces the old version and deletes components that are no longer included. To truly retire a table or app from PROD, you need the upgrade path.

Before import, use Show dependencies on any component to see what it requires. A managed import fails when a required component is missing in the target environment — the fix is to install the base managed solution first, then the dependent one.

Source Control Awareness

For enterprise ALM, the solution is also the unit of source control. The Power Platform CLI (pac) can export and unpack a solution into individual source files (pac solution clone or pac solution unpack) suitable for Git, and later pack those files back into a deployable solution. Microsoft ships Power Platform Build Tools for Azure DevOps and GitHub actions to automate export, solution checker analysis, and managed deployment. On the exam you only need awareness: source control holds the source of truth, while environments hold deployable managed builds.

Walkthrough: Contoso's Expense Copilot App

Contoso builds an expense reporting app with a copilot. The maker creates the cts publisher, then an unmanaged solution in the DEV environment containing the app, flows, a Dataverse table, an environment variable for the SharePoint receipts site, and connection references. At each milestone the team exports both formats: the unmanaged export goes to source control via pac solution unpack, and the managed export feeds the pipeline. In TEST, the import wizard prompts for the TEST receipts site and connections — no code edits required. After validation, a pipeline stage with a pre-deployment approval moves the same managed build to PROD. A week later, a bug fix ships as a solution patch, and the quarterly release clones everything back into the parent solution at version 2.0.