The environment strategy conversation you need before you build anything

I have been called into more Power Platform engagements to fix environment problems than any other single issue. Teams have built in Default. Solutions are unmanaged. There is one environment for everything and nobody knows what lives where.

The fix is not technical. It is a conversation — one that should happen before a single canvas app is opened, before a flow is created, before anyone asks what connectors are available.

Why environment strategy matters more than people think

Your environment is your deployment boundary. Every solution, every app, every flow, every Dataverse table — all of it lives inside an environment. When you get it wrong, you end up with one of three failure modes:

• The everything-in-Default disaster: Production work lives alongside personal experiments. There is no governance boundary. DLP policies are impossible to apply cleanly. This is the most common failure mode I see in mid-market organisations.
• The too-many-environments problem: Someone read the documentation and created 47 environments. Nobody knows what is live. Licensing costs are out of control. The CoE dashboard shows six hundred apps and nobody can identify the owners of four hundred of them.
• The Dev-only trap: Teams have a Development environment but no Test and no Production separation. Everything goes live from Dev. Changes are untested. Users experience half-finished features.

The right structure for most enterprise tenants

For most organisations with Power Platform as a strategic platform, I recommend this as a starting point:

• Default environment: locked down. No production solutions. Treated as a personal productivity sandbox only. DLP policy blocks everything except Microsoft-published connectors.
• Development environment: where makers build. Managed solutions exported from here. Unmanaged solutions allowed. Connected to source control via Azure DevOps pipelines.
• Test/UAT environment: where business validation happens. Managed solutions only. Business stakeholders sign off here before anything goes to production.
• Production environment: managed solutions only. Strict DLP. No maker access. Deployments happen via pipeline, not by hand.
• CoE environment: where your Center of Excellence tools live. Separate from the rest. Inventory, nurture flows, compliance tooling all here.

Large organisations may add additional environments for specific business units, regulated workloads, or geographic regions. But the five above are the core.

The naming convention nobody wants to discuss

Every environment needs a name that tells you three things instantly: who owns it, what it is for, and what its lifecycle stage is.

A convention I have used on multiple engagements:

ORG-DEPT-PURPOSE-ENV
Examples:
ACME-HR-Benefits-DEV
ACME-HR-Benefits-TEST
ACME-HR-Benefits-PROD
ACME-IT-CoE-CORE

This sounds trivial. It is not. When you are looking at thirty environments in the Power Platform admin centre six months from now, this is the difference between knowing what is live and what is not, and spending two days tracking down who owns what.

The conversation to have before anyone builds

Before a new Power Platform initiative starts, I run through this checklist with the team:

1. What business problem are we solving and what is the deployment scope?
2. Does an appropriate environment already exist, or do we need to provision one?
3. What DLP policy should apply to this environment?
4. Who is the environment admin and business owner?
5. What is the ALM path — how does code move from Dev to Prod?
6. What is the retention policy — when does this environment get reviewed or decommissioned?

The teams that skip this conversation are the ones who call me six months later asking why their production environment has four hundred unmanaged components and nobody knows what is safe to delete.

One thing to do today

If you have not already, open the Power Platform admin centre and look at your Default environment. Count the apps and flows. If there are production workloads running there, that is your first priority. Not because Default is bad, but because it was never designed to be your production environment — and it shows in the governance constraints you cannot apply to it.

Start there. Everything else builds on it.