Power Automate Environment Strategy - Dev Test Prod Done Right

Open the Power Platform Admin Center. Click on Environments. If you see one environment where every Power Automate flow runs - the default - this article is for you.

The default environment is the single biggest governance liability in Power Platform. Every licensed user in your tenant gets the Environment Maker role in the default environment. Every user can create flows, apps, and connections there. Every user’s work sits next to every other user’s work. There are no guardrails, no separation, and no way to promote tested work to production because there’s only one environment. Everything is production.

This is how most organizations run Power Automate. And it works until it doesn’t. Until someone’s test flow sends 10,000 emails to real customers. Until a maker’s experimental flow consumes all the API capacity. Until you need to roll back a change and realize there’s nothing to roll back to because there’s no dev/test/prod separation.

The 3-Environment Minimum

At minimum, you need three environments for any workload that matters:

This isn’t new. Software development has followed dev/test/prod for decades. Power Platform is software development. The fact that citizen developers build flows doesn’t change the fundamental need for environment separation.

Solutions move from Dev to Test to Prod through managed solution exports and imports. Connection references and environment variables handle the configuration differences between environments. This is Application Lifecycle Management (ALM), and it’s the only way to reliably deploy Power Automate flows at scale.

Developer Environments

Developer environments solve a specific problem: makers need a place to experiment without polluting shared environments. In the past, organizations either gave makers access to the default environment (too risky) or created shared dev environments (still messy).

Developer environments are personal sandboxes. Key facts from Microsoft’s current documentation:

• Each user can create up to 3 developer environments through the Power Platform admin center
• They include Dataverse at no additional storage cost to the tenant
• Capacity: 2 GB database, 750 flow runs per month
• They are meant for development and testing, not production use
• Auto-cleanup: disabled after 30 days of inactivity, then deleted 15 days later if not re-enabled
• The Developer Plan license is free and gives access to premium connectors for dev/test purposes

Default Environment Routing

Here’s the governance feature that ties it together. Environment routing automatically redirects makers away from the default environment and into their own personal developer environments.

When enabled, a maker who navigates to make.powerapps.com or make.powerautomate.com lands in their own developer environment instead of the default. If they don’t have a developer environment yet, one’s created automatically.

The developer environments created by routing are Managed Environments by default. This means they inherit the preconfigured settings:

• Sharing limits: excludes sharing with security groups, limited to 5 individuals
• Solution Checker: set to Warn
• Usage insights: enabled

What Do Managed Environments Actually Add?

Managed Environments give admins sharing limits, solution checker enforcement, usage insights, maker welcome content, and environment-level data policies. They layer governance controls on top of any existing environment without changing how makers build. The tradeoff is that users who run resources in a Managed Environment need premium licensing.

Managed Environments are not a separate environment type. They’re a set of capabilities you enable on an existing environment.

What Managed Environments add:

Managed Environments require premium licensing for users who run resources. This is the tradeoff. You get governance controls, but you need to plan your licensing accordingly.

Environment Groups

Environment groups let you organize environments and enforce rules at the group level. Instead of configuring sharing limits, solution checker, and other settings on each environment individually, you configure them once on the group and every environment in that group inherits the rules.

This matters when you have 10, 20, or 50 environments. Configuring each one manually doesn’t scale. Environment groups make it manageable.

The recommended pattern:

When environment routing creates a new developer environment, it can automatically place it in the Developer environments group. The maker gets a governed environment from day one without any admin intervention.

Connection References and Environment Variables

These are the bridge between environments. Without them, you can’t move flows from dev to test to prod.

Connection references abstract the authentication. In dev, the connection reference points to your dev SharePoint site. In test, it points to the test site. In prod, the production site. The flow itself is identical across all three environments. Only the connection reference value changes.

Environment variables store configuration that differs per environment. Email addresses, URLs, thresholds, feature flags. The flow references the variable, not the value. When you import the solution into a new environment, you set the variable values for that environment.

Example of the same flow across three environments:

The flow logic never changes between environments. Only the configuration changes. This is what makes ALM possible.

The Full Picture

Putting it all together:

1. Makers start in their own developer environment (created by environment routing)
2. They build flows inside solutions using connection references and environment variables
3. When ready, they export the solution and import it into a shared test environment
4. Business stakeholders validate in test
5. The solution is promoted to production as a managed solution
6. Each environment is in an environment group with appropriate governance rules
7. The default environment is locked down. No new flows are built there.

This isn’t aspirational. This is the environment strategy that Microsoft recommends and that the platform supports today. The tooling exists. The licensing model supports it. The only thing missing in most organizations is the decision to implement it.

Start with What You Have

If you’re running everything in the default environment today, here’s the pragmatic path forward:

The goal isn’t to migrate everything overnight. The goal is to stop making the problem worse (new flows in the default environment) while gradually fixing the existing state.

---

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

1. Naming Conventions That Scale
2. Environment Strategy - Dev Test Prod
3. Solution-Aware Flows
4. Flow Inventory
5. Pipelines - Dev to Prod
6. CoE Starter Kit
7. AI-Powered Flow Review
8. Versioning and Source Control
9. The Governance Repo
10. Weekly Governance Digest

---

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.