What it does

How environments are laid out so apps can move from where they're built to where people use them. The minimum viable shape is separate development and production; Microsoft's recommendation adds at least one test environment so you can validate the deployment itself, not just the app.

Key facts

• Any healthy practice includes a test environment before production. Some organisations add UAT, SIT, pre-production and training on top.
• You can import a solution into an environment on a newer platform version than where it was exported. You can't reliably go the other way, because the older environment may be missing components the solution needs.
• Environments update in six service stations defined largely by geography, applied in sequence. Environments in different stations sit at different versions at any given moment.
• The practical consequence: development environments should sit in a station that updates before or with production, not after. Development in North America (station 5) with production in Canada (station 2) is the wrong way round.
• Every environment, with or without Dataverse, consumes at least 1 GB of capacity. Provisioning is bounded by available database capacity rather than a per-licence environment count.
• Environment routing directs makers into their own personal developer environment instead of the default environment when they open the maker portal. Routed developer environments are Managed Environments by default and inherit the rules of an assigned environment group.
• Developer environments created by routing don't consume the tenant Dataverse quota. Makers are assigned the admin role in their own environment.
• Multi-rule routing lets different security groups land in different environment groups, evaluated in priority order, with the default environment as the fallback when no rule matches.
• Routed developer environments come preconfigured with sharing limits, solution checker set to Warn and usage insights on.
• Creating an app or flow in a managed developer environment doesn't need a premium licence. Running one does.
• Environments have a canvas authoring refresh cadence — frequent (multiple times a month, the default) or moderate (at least monthly).

When to use / skip

Three environments is the floor for anything a business will depend on, and per-maker developer environments are now cheap enough that there's no good argument for makers building in the default environment. Environment routing is the mechanism that makes that stick without asking makers to remember anything. Where you can reasonably stop short is a small internal tool with one maker and a genuine tolerance for downtime — dev and production, promoted by hand, is a defensible answer there. What isn't defensible is production apps living in the default environment, which is shared by everyone in the tenant and has no meaningful boundary.

Configuration decisions

• How many environments beyond dev, test and production the client's governance actually needs, versus how many they'll ask for.
• Which geography each environment sits in, aligned so development is never on a later service station than production.
• Whether environment routing is on, for new makers only or for everyone, and which environment group the routed environments join.
• Whether developer environments are long-lived or created per work item and rehydrated from source control.
• Refresh cadence per environment — leaving production on frequent means it takes canvas authoring updates as they ship.
• What the default environment is for, once routing is in place, and whether existing content in it needs relocating.

Gotchas

• The service station ordering trap is subtle and expensive. Everything works for months, then a solution exported from a newer dev environment fails to import into an older production one, usually the week before a release.
• Managed Environments isn't included in the Developer plan entitlement for running assets. Routed developer environments are managed by default, so makers need premium licences to run what they build.
• Turning routing on doesn't clean up the default environment. Existing apps stay where they are and someone has to decide what happens to them.
• Non-managed developer environments are unaffected by routing, so an estate with a mix of both won't behave uniformly.
• If developer environment creation fails, the maker silently lands in the default environment — the exact outcome routing was meant to prevent.
• A maker with several developer environments is routed to the first one alphabetically, which is rarely the one they were last working in.

Consultant notes

• Draw the environment diagram in week one with regions on it. It's a ten-minute conversation that prevents the version-ordering problem, and nobody thinks to ask about it later.
• Frame per-maker developer environments as a safety measure for the maker, not a control imposed on them. "Your own space where nobody else can break your work" lands better than "we're stopping you using the default environment".
• Price default environment remediation honestly if you inherit it. Sorting out what's business-critical, what's abandoned, and what has no owner is discovery work, not a migration task.
• Get the licensing position on Managed Environments confirmed in writing before designing around routing. It's the assumption most likely to be wrong, and it changes the shape of the answer.

---

Worth revisiting after the next release wave, or if the developer environment licensing position for Managed Environments changes.