Governance Playbook: Power Platform Environment Strategy

What You’ll Learn

This playbook provides a practical framework for designing your Power Platform environment strategy. It covers how many environments you need, how to structure them, what DLP policies to apply, and how to scale as your organisation grows.

Most governance failures start with a bad environment strategy. Get this right and everything else — DLP, ALM, security — becomes straightforward.

Why Environment Strategy Matters

Every Power Platform tenant starts with a single default environment. This works fine for the first few makers, but problems appear quickly:

• No isolation: A broken flow in development affects production users
• No testing: Changes go live immediately with no validation
• DLP conflicts: A connector policy that works for IT breaks marketing’s workflows
• Data mixing: Test data and production data in the same Dataverse instance
• No accountability: Everyone is an admin in the default environment

The cost of fixing a bad environment strategy retroactively is significantly higher than designing it correctly from the start.

Environment Types

Default Environment

Every tenant gets one. It cannot be deleted. Key characteristics:

• Every licensed user has Maker access automatically
• No Dataverse database by default (can be added)
• Often called the “personal productivity” environment
• Should be treated as a sandbox, not production

Recommendation: Let makers experiment here, but never run business-critical apps from the default environment.

Developer Environments

Individual sandbox environments for makers to build and test without affecting others.

• One per active maker (or shared among a small team)
• Dataverse included (no additional cost with developer plan)
• Reset or delete periodically to manage storage
• No DLP restrictions or minimal restrictions (encourages experimentation)

Recommendation: Provision automatically when a maker completes onboarding. Reclaim after 90 days of inactivity.

Shared Development Environment

A team-level environment where collaborative development happens.

• Shared by a project team (3-10 people)
• Contains shared data connections and test data
• Managed solutions used for all development
• DLP policies match production (catches issues early)

Test / UAT Environment

Pre-production environment for validation.

• Mirrors production configuration (DLP, security roles, connections)
• Contains representative test data (never production data)
• Used for user acceptance testing before promotion
• Refreshed regularly from a sanitised production backup

Production Environment

Where business-critical apps and flows run.

• Strictly controlled access (no direct editing)
• Changes deployed only via managed solutions
• Full audit logging enabled
• Monitored for performance and errors
• DLP policies enforced with no exceptions

Strategy by Organisation Size

Small (< 50 makers)

Environment	Purpose	DLP Profile
Default	Personal productivity	Permissive
Shared Dev	Collaborative building	Standard
Production	Live apps and flows	Restrictive

Three environments is the minimum viable strategy. Skip the separate test environment initially — use the shared dev environment for UAT. Add a dedicated test environment when you have more than 5 production apps.

Medium (50-500 makers)

Environment	Purpose	DLP Profile
Default	Personal productivity	Permissive
Developer (pooled)	Individual sandboxes	Permissive
Shared Dev (per team)	Team development	Standard
Test / UAT	Pre-production validation	Restrictive
Production	Live workloads	Restrictive

At this scale, you need team-specific development environments. Create one shared dev environment per business unit or project team. The test environment becomes essential — direct promotion from dev to production is too risky.

Enterprise (500+ makers)

Environment	Purpose	DLP Profile
Default	Personal productivity	Permissive
Developer (individual)	Personal sandboxes	Permissive
Shared Dev (per team)	Team development	Standard
Test / UAT (per team)	Pre-production validation	Restrictive
Pre-Production	Final staging	Production-mirror
Production	Live workloads	Restrictive
DR / Failover	Disaster recovery	Restrictive

Enterprise deployments need dedicated test environments per team, a pre-production staging environment that exactly mirrors production, and potentially a disaster recovery environment for critical workloads.

DLP Policy Alignment

Each environment tier should have a matching DLP policy:

Permissive (Default, Developer)

• Business data group: All standard connectors + common premium connectors
• Non-business data group: Social media, personal services
• Blocked: None (or only clearly dangerous connectors)
• Purpose: Let makers experiment freely

Standard (Shared Dev)

• Business data group: Approved business connectors only
• Non-business data group: Everything not explicitly approved
• Blocked: Known risky connectors (custom connectors without approval)
• Purpose: Match production rules during development

Restrictive (Test, Production)

• Business data group: Only connectors used by approved solutions
• Non-business data group: Everything else
• Blocked: All custom connectors not on the approved list
• Purpose: Prevent unapproved integrations in production

Naming Convention

Consistency in naming prevents confusion as environments multiply. Use this pattern:

{OrgPrefix}-{Purpose}-{Team/Region}

Examples:
LCK-DEV-Marketing
LCK-TEST-Finance
LCK-PROD-Global
LCK-SANDBOX-JSmith

Apply the same convention to:

• Environment names
• Solution publisher prefixes
• Connection reference names
• Environment variable names

Security Roles

Default Environment

• All users: Environment Maker (automatic)
• IT team: System Administrator

Development Environments

• Assigned makers: Environment Maker
• Team lead: System Administrator
• IT team: System Administrator

Production Environment

• End users: Basic User (or custom role with minimal permissions)
• App owners: System Customizer (read-only on schema changes)
• IT team: System Administrator
• No one gets Environment Maker in production

Environment Lifecycle

Provisioning

Automate environment creation where possible:

1. Maker requests environment via a Power App or service desk ticket
2. Approval workflow routes to COE lead
3. Approved requests trigger a Power Automate flow that calls the admin API
4. Environment created with correct DLP policy, security roles, and naming
5. Maker notified with access details

Monitoring

Track these metrics monthly:

• Environment count: Are you creating faster than decommissioning?
• Storage consumption: Which environments use the most Dataverse storage?
• Active makers per environment: Are any environments unused?
• Apps per environment: Are production environments overloaded?

Decommissioning

Inactive environments waste licences and create security surface area. Implement a review cycle:

• Developer environments: Review quarterly, reclaim after 90 days of inactivity
• Shared dev environments: Review when projects complete
• Test environments: Reset monthly, rebuild from sanitised production data
• Production environments: Never decommission without a migration plan

Common Mistakes

1. Running production from the default environment: The default environment has no isolation and everyone has maker access. Move production workloads to a dedicated environment.

2. One DLP policy for all environments: Developer environments need freedom to experiment. Production environments need strict controls. Use separate DLP policies per environment tier.

3. No naming convention: When you have 20+ environments, “John’s Test” and “Marketing Stuff” are meaningless. Enforce naming from day one.

4. Skipping the test environment: “We’ll test in dev” inevitably leads to untested changes reaching production. A separate test environment with production-like data catches issues before users see them.

5. Manual environment provisioning: If creating an environment requires a support ticket and three days of waiting, makers will build everything in the default environment instead. Automate provisioning.

Taking It Further

• Use the COE Maturity Assessment to benchmark your current governance maturity
• Generate environment-specific DLP policies with the DLP Policy Planner
• Create a governance policy document with the Governance Policy Generator
• Review licensing implications in the Power Platform Licensing Guide 2026