Environment strategy

What it does

An environment is the container for Dataverse, apps, flows, agents and their security. Environment strategy is the set of decisions about how many you have, what each is for, who can create things in them, and how work moves between them — which in practice is the same thing as your ALM story and most of your governance story.

Key facts

ALM needs separate development and production environments as a minimum. Microsoft's recommendation is at least one test environment as well, so development, test and production.
The default environment is created automatically in the region closest to the tenant's default region. Every new user is added to the Maker role in it automatically, and it can't be deleted — only renamed.
Users are not automatically added to the Environment Admin role in the default environment.
Microsoft recommends provisioning Dataverse in any environment where makers build things that will be shared, because that's what makes the assets solution-aware and ALM-ready.
Environment types (production, sandbox, developer, trial, and where entitled, Managed Environments) carry different capabilities, backup behaviour and licensing treatment.
Environment groups let you apply rules and settings across a set of environments rather than one at a time, which is how the developer-environment sprawl problem gets managed.
Managed Environments is the gate on several governance controls, including sharing limits, maker welcome content, weekly digests and a number of the newer agent and connector policies.
Copies and restores move data as well as configuration, which is why sandbox refreshes are a data governance event and not just an ALM convenience.

When to use / skip

The proportionate default for a client of any size: a locked-down default environment, one production environment per solution boundary, matching test and development environments, and per-developer environments for anyone doing real customisation. That's more environments than clients expect and fewer than most large estates end up with.

Split environments when there's a genuine boundary — different data residency, different security models, different release cadences, different owners. Don't split because two applications are conceptually different; that's what solutions are for, and every extra environment is another set of connection references, another deployment target and another thing to keep in sync. The cost of an environment isn't capacity, it's the ongoing operational tax.

The one non-negotiable is the default environment. It's created for you, every user is a maker in it, it can't be deleted, and left alone it becomes the place where business-critical things get built by people who don't know they're building business-critical things. Treat it as personal productivity space only, apply a restrictive data policy, and have a documented route for moving anything valuable out.

Configuration decisions

What the default environment is for, and what policy enforces that. This is the first decision, not the last.
How many production environments, and on what boundary — data residency, security model, release cadence, ownership.
Whether developers get their own environments, and how those are provisioned and reclaimed.
Whether Managed Environments is in scope, since a lot of the governance you'll want to promise depends on it.
Where Dataverse is provisioned, given a Dataverse-less environment can't hold solutions properly and will need rebuilding later.
How sandbox refreshes handle production data — masked, subset, or full copy with an access restriction.

Gotchas

Renaming the default environment to something like "Personal Productivity" is a five-minute job that changes behaviour more than most governance policies. Almost nobody does it.
Migrating apps and flows out of the default environment later is genuinely painful — connection references, flow ownership, sharing and any hard-coded environment references all need attention. Microsoft has a white paper on it, which tells you how common the problem is.
Environment region is set at creation and can't be changed. A client with a data residency requirement discovered after the fact is looking at a rebuild.
Sandbox copies bring production data with them. If the sandbox has looser access, you've just created a data exposure and it won't show up in any security review.
Developer environments expire and get cleaned up. Work living only in one and not in source control disappears, and it always turns out to be the thing nobody committed.
Every new environment needs its DLP policy, its security roles and its connection references. The tax is per environment, forever.

Consultant notes

Do environment strategy in week one, before anyone builds anything. It's cheap to decide and expensive to retrofit, and it's the decision the rest of the delivery hangs off.
Get the default environment policy signed off by whoever owns risk, not just by the platform team. It's the single highest-value governance change available and it needs air cover.
Push for source control from the start rather than treating environments as the system of record. Environments are deployment targets; the repository is the truth.
Where a client already has sprawl, don't try to consolidate everything. Inventory it, find the business-critical things sitting in the default environment, and move those first.

Sticky note: check the default environment policy again after any tenant-wide licensing or Managed Environments change