Environment and ALM strategy

What it does

The shape of the tenant: which environments exist, what each is for, how work moves between them, and what stops everything ending up in the default environment. Get this right in month one and the rest of the delivery is normal software work. Get it wrong and you spend year two doing archaeology.

Key facts

Environment types have defined purposes. Default ships with every tenant and is intended for Microsoft 365 personal productivity, not permanent work. Production is for live use. Sandbox supports copy and reset and is the natural home for test and ALM build environments. Developer environments are personal maker workspaces — up to three per maker, not counted against tenant capacity, and removed after 90 days of disuse if the owner doesn't respond to notifications.
Each environment holds at most one Dataverse database, and each non-trial, non-developer environment consumes 1 GB of tenant capacity to provision.
Dynamics 365 apps have to be chosen at environment creation. They can't be installed or uninstalled later, so an unnecessary install becomes a permanent dependency problem for your solutions.
Solutions carry metadata and configuration, not business data. Managed solutions are what you deploy to anything that isn't the development environment for that solution, and should be produced by a build process rather than hand-exported.
Solution upgrades delete components that are no longer in the upgraded version; updates and patches do not, and can't remove components at all.
Managed Environments turn on the governance layer: sharing limits, solution checker enforcement, environment groups and rules, environment routing, extended backup retention, usage insights.
Environment groups apply rules across many environments at once. An environment must be managed to join one, can only be in one group at a time, and while a group rule manages a setting the individual environment setting is locked.
Default environment routing redirects makers into a personal developer environment instead of the default. Routed environments are managed by default, and pairing routing with a group means new environments are governed from the moment they exist.
Power Platform pipelines automate solution promotion, can enforce solution checker rules before deployment, and support approvals. Pipeline definitions live in a host environment — Microsoft-managed by default, or one you run yourself.
Git integration and the Power Platform Build Tools cover the cases where pipelines aren't enough: branching, merging, YAML pipelines, and build artefacts under proper source control.

When to use / skip

Three environments per workload — development, test, production — is the floor for anything a business depends on, and development environments should be single-purpose, disposable and easy to recreate. Below that you're testing in production and calling it agility.

Pipelines are enough for most Power Platform delivery, and consultants routinely reach for Azure DevOps when they didn't need to. If the team is low-code, the solution is self-contained, and the release cadence is "when it's ready", pipelines with solution checker enforcement and an approval step will serve you well and the makers will actually use them. Move to full DevOps when any of these appear: pro-code components that need building, several developers working on the same solution and needing branches, a release process that has to align with other systems, or an audit requirement for source control as the single source of truth. Those are the conditions where Git integration and the Build Tools earn their setup cost. Everything else is ceremony.

Configuration decisions

How you group environments — by business unit, by region, by product, by lifecycle stage — and what rules each group enforces. Name the convention before anyone creates environment number four.
Whether to turn on default environment routing, and whether to disallow manual developer environment creation alongside it.
How the default environment gets locked down: a data policy blocking everything blockable, custom connector URL patterns blocked, admin access trimmed, and a rename to something honest like "Personal Productivity".
Single solution or multiple solutions per workload, and whether you're setting a preferred solution in each development environment so assets don't drift into the default solution.
Pipelines or DevOps, and if pipelines, whether you need your own host environment or the Microsoft-managed one will do.
What happens to what's already in the default environment: leave it, move it to the owner's developer environment, move it to a shared production environment, or quarantine it.

Gotchas

Assets created outside a custom solution land in the default solution, shared with every other maker in that environment. Untangling which components belong to which app afterwards is slow and thankless — set preferred solutions early.
Developer environments disappear after 90 days of inactivity if the owner ignores the notifications. Work that only ever existed there goes with them.
Environment capacity is tenant-wide and shared. A proliferation of environments quietly consumes it and the first symptom is somebody being unable to create the one they actually need.
The Dynamics 365 apps decision at creation time is irreversible. Installing them "just in case" creates dependencies that follow every solution you export.
Group rules lock the corresponding environment settings. That's the point, and it will still surprise the environment admin who can't change their own setting.
Moving a flow between environments breaks connections unless connection references were used from the start. Retrofitting them into an existing estate is real work.
You can't block access to the default environment, only reduce what's possible in it. Anyone promising to switch it off is wrong.

Consultant notes

Do the environment strategy in the first fortnight, before anyone has built anything worth migrating. It's a two-day workshop that saves a six-figure remediation.
Sell governance as the thing that lets makers move faster, because with routing and groups in place it genuinely is — they get an environment instantly and it's already compliant.
Default environment cleanup is a project in its own right on any tenant more than two years old. Scope it separately and use the usage-based triage: unused goes to quarantine, single-maker unshared goes to a developer environment, widely shared gets a proper home.
Start clients on pipelines and let the requirement for DevOps prove itself. Introducing YAML to a low-code team on day one is how adoption dies.
Push for connection references and environment variables from the first solution. They cost nothing at the start and are the difference between a deployable solution and a manual reconfiguration exercise every release.

Worth a fresh look whenever the tenant crosses another dozen environments, or the first time a deployment breaks because of the default solution