Environment strategy for Power Apps

What it does

The topology decision: how many environments a tenant runs, what each one is for, how makers get one, and what stops the default environment becoming the estate. Microsoft's adoption guidance now has a clear opinion on this, and it's worth following rather than inventing your own.

Key facts

Environment types have defined intents. Default is for Microsoft 365 personal productivity work, not permanent solutions. Production is for permanent work. Sandbox supports copy and reset and suits testing and ALM builds. Developer environments are personal maker workspaces.
Developer environments: up to three per maker, they don't count against tenant capacity, they're turned off after 90 days of no use and removed if the owner doesn't respond, and Dynamics 365 apps aren't available in them.
Every environment except trial and developer consumes 1 GB of tenant capacity to provision. Capacity is shared across the tenant.
Environment routing redirects makers away from the default environment into a personal developer environment, creating one where needed. It requires managed environments, and environments created by routing are managed by default.
Environment groups need managed environments too. An environment belongs to exactly one group, can be moved between groups, and groups can't nest. Rules published to a group lock the corresponding environment settings so an environment admin can't override them.
Group rules currently cover sharing controls for canvas apps, usage insights, maker welcome content, solution checker enforcement, back-up retention and AI-generated descriptions. There's no rule for applying a data policy — you align those by convention.
Sharing limits apply only to future sharing. Applying a limit of 20 to an environment where things are already shared with 200 people changes nothing for those 200.
Developer Plan users can create and preview in a managed developer environment. Running the resources needs an appropriate licence.
Dynamics 365 has to be enabled when the environment is created. You can't add it later.

When to use / skip

Every tenant needs this, and the only question is whether it gets written down before or after the mess. The default position from Microsoft is now well-defined and I'd follow it: secure the default environment, rename it something like Personal Productivity so its purpose is legible, turn on environment routing so makers land in their own developer environment, and put those developer environments in a group with rules. That's the foundation and it's defensible in front of any security function.

When to split beyond that is the harder call, and the honest test is compatibility rather than tidiness. Two apps that both use the Contact table for different purposes don't belong together. Two apps that share a Customer table absolutely do — separating them creates duplicate data and a synchronisation problem you'll own forever. Beyond that, split for data residency, for genuinely sensitive data, for regulatory separation, and for user geography where performance matters. Don't split per project out of neatness; every environment is capacity, an ALM path and an administrative surface.

Development is the exception where isolation wins. Development environments should be single-purpose, disposable and easy to recreate. Testing is the opposite — test together whatever runs together in production, or you won't find the compatibility problems until users do.

Configuration decisions

How makers get environments: routing only, admin request process, or both. Restricting manual creation of production environments to admins is the recommended default.
Whether developer environments are individual or whether a shared development environment is better for the team. Individual gives isolation; shared reduces the merge problem for small teams working on one app.
The group structure — by lifecycle stage, by business unit, by region, or a combination — and the naming convention that implements it, since groups don't nest.
Which rules go on which group, and specifically the sharing limits and solution checker level per environment type. Microsoft's suggested pattern is block-and-email in default and production, warn in developer and sandbox.
Whether Dataverse is provisioned in environments where makers build things they'll share. It should be, because that's what makes assets ALM-ready.
Whether to enable Dynamics 365 at environment creation, on the basis of what might get installed later rather than what's needed today.
How the app estate gets patched: whether the topology supports fixing version 1.0 in production while version 2.0 is in development.

Gotchas

Environment routing only covers makers arriving via make.powerapps.com today. Other entry points still land in the default environment, so routing alone doesn't finish the job.
Makers with a premium or Developer Plan licence can still create developer environments manually, outside any group, with none of your rules applied. Restrict creation in tenant settings or the gap stays open.
Group rules lock settings while the environment is in the group. Remove it and it keeps the settings, but an environment admin can now change them.
Moving developer environments into region or business-unit groups is a manual action today. If your design depends on it happening automatically, check whether the admin connector supports it yet.
The 90-day developer environment cleanup is a feature until someone's proof of concept evaporates. Anything worth keeping belongs in source control, not in a developer environment.
Assets built outside a custom solution land in the default solution and are painful to promote. Setting a preferred solution per environment is the cheap fix and almost nobody does it unprompted.

Consultant notes

Do the default environment first. Renaming it, applying a data policy that permits only unblockable connectors, and limiting sharing is a week's work that prevents years of migration.
Get the existing estate inventoried before proposing a topology. The CoE Starter Kit's environments dashboard is the fastest route, and what it turns up usually reshapes the proposal.
Environment strategy is a governance deliverable, not an IT one. It needs a named owner in the business who can approve exceptions, or every request escalates to whoever answers first.
Be clear that this evolves. Microsoft ships environment features most waves, and a strategy written as a fixed document rather than a reviewed standard goes stale within a year.
The developer environment migration path is the sales pitch that lands with makers: your own space, your own rules, and a pipeline to production when you're ready. Framed as a restriction it gets resisted; framed as an upgrade it doesn't.

Worth a look each wave — environment groups and routing have gained capabilities every release since they shipped