Power Platform makes it easy to build and change business applications. That speed does not remove the engineering work around a consequential release. It makes the control model more important because Dataverse tables, model-driven apps, canvas apps, cloud flows, plug-ins, security roles, connection references, environment variables, and external services can cross ownership and deployment boundaries in one solution.
How to use this checklist
Treat every item as an evidence question, not a policy statement. “We usually do that” is not a yes. A control passes when the team can show the current record, name its owner, and repeat the action on the next release.
The amount of control should match the workload. A departmental app with reversible changes does not require the same gates as a Dynamics 365 solution carrying revenue, service, identity, or regulated data. Microsoft likewise recommends choosing the level of ALM formality according to workload complexity and criticality in its guidance on effective ALM practices.
The evidence exists, the owner is known, and the control is repeatable.
The practice happens, but it depends on manual memory, unclear ownership, or evidence assembled after the fact.
The control is absent, cannot be demonstrated, or is bypassed for the current release.
Original field artifact
Ten controls across the release lifecycle
The ten checks are grouped into five connected control areas. A pipeline cannot compensate for an ambiguous release boundary, and a clean import cannot compensate for missing acceptance or recovery ownership.
Release boundaries
Define what is being released, where it can change, and who can authorize it.
- The business capability, affected users, criticality, data sensitivity, integrations, and acceptance owner are recorded.
- Development, test, acceptance, and production environments each have a stated purpose, access model, data policy, and accountable owner.
Solution and source architecture
Make component ownership and the deployable source of truth unambiguous.
- Custom publishers, solution boundaries, table ownership, shared components, dependencies, layering, and upgrade behavior are intentional.
- The team can identify the authoritative source, reproduce the solution artifact, and connect its version to the approved change set.
Configuration and deployment
Move one known artifact through known stages without hidden environment work.
- Connection references, environment variables, secrets, endpoints, ownership, and target-specific values are separated from the solution and assigned deliberately.
- The deployment path, stage order, deployment identity, permissions, preflight checks, approvals, notes, and retained run history are explicit.
Verification and recovery
Prove both that the change works and that the organization can recover when it does not.
- Static analysis, dependency validation, automated tests, regression checks, security review, data validation, and business acceptance match the release risk.
- The release has a rehearsed failure response: stop conditions, rollback or forward-fix decision, data recovery boundary, communication owner, and production verification steps.
Operations and ownership
Leave production controlled after the deployment window closes.
- Monitoring, flow and plug-in failure visibility, support triage, service identities, connection ownership, license dependencies, and escalation paths have named owners.
- Emergency changes follow a controlled path back into source, testing, documentation, and the next managed release instead of becoming a permanent production-only layer.
Architecture decisions the checklist should expose
ALM problems often appear as failed imports or unreliable pipelines, but the failure begins earlier. The organization has not decided how environments, solutions, source, configuration, identities, and release evidence fit together.
Environment topology is a risk decision
An environment is a security, data, operational, and lifecycle boundary—not just a destination in a deployment diagram. Record why each environment exists, who can make changes, what data it may contain, which integrations are live, and how it is refreshed or recovered. Microsoft's Power Platform ALM basics describe environments as containers that separate apps with different roles, security requirements, or audiences.
Solution boundaries decide future coupling
Do not split or combine solutions merely to make today's import convenient. Decide component ownership, shared-table strategy, publisher, release cadence, dependencies, and the way managed layers will behave downstream. Microsoft's current guidance on organizing solutions distinguishes a single-solution approach, multiple solutions in one development environment, and multiple solutions with dedicated development environments. Complexity alone does not make the most modular option correct; the dependency and ownership model does.
Source control must be authoritative in practice
A repository is not the source of truth when production contains unmanaged changes, the build cannot be reproduced, or makers can change shared components without returning them to source. Native Dataverse Git integration is designed for development environments; downstream test and production environments still receive built managed artifacts through deployment paths. See Microsoft's Dataverse Git integration overview.
Configuration belongs outside the artifact
Environment-specific endpoints, connections, keys, and ownership should not require editing the solution after import. Environment variables separate target values from the objects that consume them, while connection references identify the connection required by solution-aware components. Record where each value comes from, who may change it, and how a failed binding is detected. Microsoft's guide to environment variables in solutions explains the underlying portability model.
Deployment identity and approval are separate decisions
State which identity deploys, which permissions it needs, who owns its lifecycle, who approves the release, and what the approval means. Native Power Platform pipelines can preserve stage order and move the same solution artifact from test to production. Delegated deployment adds an explicit service principal or stage owner, but it also introduces ownership and permission requirements that must be governed. Review Microsoft's guidance for running Power Platform pipelines and delegated deployments.
The release-ready record
Before approving production, a reviewer should be able to open one connected record and answer the questions below. The tools can vary; the evidence cannot.
Requirement, business owner, risk, acceptance criteria, and scope.
Solution name and version, source revision, build, dependencies, and hash.
Environment, configuration values, connection bindings, and data actions.
Analysis, tests, reviews, exceptions, business acceptance, and approvers.
Stop conditions, rollback or forward-fix path, owner, and verification.
Solution Checker can contribute static-analysis evidence, and pipeline preflight can catch missing dependencies and other import problems. Neither proves business acceptance, operational safety, or successful recovery on its own. The Power Apps checker guidance explicitly notes that checker use does not guarantee a successful solution import.
Warning signs that the pipeline is masking weak ALM
- The team exports from whichever environment appears most current.
- Production fixes are made directly and reconstructed in source later.
- One person owns the deployment, connections, approvals, and recovery steps.
- Solution versioning changes, but nobody can identify the source revision.
- Connection or environment values are discovered during the import dialog.
- Testing proves the feature demonstration but not regression or operations.
- A release is called reversible without a tested data-recovery boundary.
- Managed solutions coexist with unexplained unmanaged layers in production.
For compatible workloads, Power Platform can block unmanaged customizations so downstream changes come through approved ALM paths. That control has documented limitations and should be assessed against the actual Dynamics 365 and Power Platform features in the environment before it is enabled. See Microsoft's block unmanaged customizations guidance.
If several warning signs are present, do not begin with pipeline replacement. First define the target environment, solution, source, identity, testing, approval, recovery, and ownership model. Then choose native pipelines, GitHub Actions, Azure DevOps, or another approved tool against those decisions.