Env Strategy

Skill: Environment Strategy

When to Use

Trigger when designing environment topology, choosing environment types, provisioning environments, setting up developer environments, configuring Managed Environments, planning multi-geo deployments, or establishing environment naming conventions.

Environment Types

Decision Table: Which Environment Type?

Naming Convention

Use a consistent pattern across all environments:

Copy code
[Org]-[Project]-[Stage]-[Region]

Examples:

Rules:

• Never use special characters or spaces (Power Platform admin APIs handle them poorly)
• Include the region suffix for multi-geo tenants
• Match the environment name to the solution name where possible
• Document the naming convention in your governance wiki — consistency matters more than the specific format

Standard Environment Topology

Minimum Viable (Small Team)

Copy code
Default (leave alone — personal productivity only)
  │
Developer environments (auto-provisioned per maker)
  │
[Project]-Dev (sandbox, unmanaged solutions)
  │
[Project]-Prod (production, managed solutions only)

Recommended (Enterprise)

Copy code
Default (locked down — DLP, no premium connectors)
  │
Developer environments (auto-provisioned, DLP-restricted)
  │
[Project]-Dev (sandbox, unmanaged, maker workspace)
  │
[Project]-Test (sandbox, Managed Env, CI/CD target, managed solutions)
  │
[Project]-UAT (sandbox, Managed Env, user acceptance)
  │
[Project]-Prod (production, Managed Env, managed solutions only)
  │
[Shared]-Services (production, shared components, CoE)

Multi-Project Enterprise

Copy code
Shared-Platform-Prod      ← CoE, shared connectors, base solution
  ├── ProjectA-Dev / Test / UAT / Prod
  ├── ProjectB-Dev / Test / UAT / Prod
  └── ProjectC-Dev / Test / UAT / Prod

Developer Environments

Developer environments are free, personal, and isolated. They are the recommended starting point for all makers.

Key Facts

• Free — included with Power Apps Developer Plan (self-service sign-up)
• Up to 3 per user
• Auto-cleanup — turned off after 90 days of inactivity, then deleted if owner doesn't respond
• Cannot share apps or flows with other users
• Dataverse included — full schema creation, no capacity charge
• No Dynamics 365 apps — D365 apps cannot be installed
• Managed Environments NOT included — Developer Plan does not entitle Managed Environment features at runtime

When to Use Developer Environments

• Learning and experimentation
• Personal productivity apps (single user)
• Initial prototyping before moving to a shared sandbox
• Testing Web API scripts against a disposable Dataverse instance

Default Environment Routing

Automatically redirect new makers away from the default environment to personal developer environments:

Copy code
Power Platform Admin Center → Settings → Environment routing
  → Enable "Route new makers to their own personal developer environment"

This prevents the default environment from becoming a dumping ground.

Environment Groups

Environment groups allow administrators to manage environments as collections and apply rules consistently.

Setup

Copy code
Power Platform Admin Center → Environment groups → New group
  → Add environments → Apply rules

Common Group Patterns

Environment Group Rules

Managed Environments

Managed Environments is the governance overlay for Power Platform. It adds premium controls on top of any environment type (except Developer at runtime).

When to Enable

Feb 2026 mandate: Power Platform Pipeline target environments must be Managed Environments. Auto-enabled on pipeline targets starting February 2026.

Key Capabilities

Licensing

Managed Environments is included with:

• Power Apps Premium (per-user)
• Power Automate Premium (per-user)
• Dynamics 365 Enterprise licenses
• Copilot Studio licenses
• Power Pages licenses

NOT included with: Developer Plan (at runtime), M365 seeded licenses, trial licenses.

Environment Variable Cascading

Environment variables let you define configuration once in a solution and set different values per environment.

Pattern

Copy code
Solution contains:
  environmentvariabledefinition: contoso_ApiBaseUrl (type: String)
    └── environmentvariablevalue: (no default — set per environment)

Dev environment:   contoso_ApiBaseUrl = "https://api-dev.contoso.com"
Test environment:  contoso_ApiBaseUrl = "https://api-test.contoso.com"
Prod environment:  contoso_ApiBaseUrl = "https://api.contoso.com"

Best Practices

• Never set default values in the solution for environment-specific config — force explicit values per environment
• Use deployment settings files to automate value injection during CI/CD (see alm skill)
• Secret type environment variables reference Azure Key Vault — use for API keys, connection strings
• JSON type for complex configuration (feature flags, endpoint maps)

Multi-Geo Considerations

Geo Naming in Environment Names

Copy code
Contoso-HR-Prod-AU    ← Australia
Contoso-HR-Prod-EU    ← Europe
Contoso-HR-Prod-US    ← United States

Environment Lifecycle

Copy code
Create → Configure (DLP, Managed Env, security) → Active
  │
  ├── Copy (sandbox → sandbox, production → sandbox)
  │
  ├── Reset (sandbox only — wipes data, keeps config)
  │
  ├── Backup → Restore (production: up to 28 days)
  │
  └── Delete (permanent — no undo)

Backup & Restore Cadence

Pre-Deployment Backup

Always take a manual backup before deploying to production:

powershellCopy code
# PowerShell — backup before deployment
$envId = "00000000-0000-0000-0000-000000000000"
$backupLabel = "Pre-deploy-v2.1.0-$(Get-Date -Format 'yyyy-MM-dd')"

# Using Power Platform admin connector or Admin API
# Power Platform Admin Center → Environments → [env] → Backups → Create

Anti-Patterns

• Everyone builds in the default environment — leads to ungoverned sprawl, no ALM possible, data comingled
• No DLP on developer environments — makers learn bad habits with unblocked connectors, then can't deploy to prod
• Manual environment creation for each developer — use developer environments (free, self-service, auto-cleanup) instead
• No Managed Environments on pipeline targets — will break after Feb 2026 mandate
• Skipping the test/UAT stage — deploying from dev straight to production with no intermediate validation
• Using production environment for development — risk of data corruption, no reset capability
• No naming convention — impossible to identify environment purpose at scale
• Ignoring environment variable cascading — hardcoding URLs/keys per environment instead of using env vars in solutions
• Creating sandbox environments without cleanup plan — sandbox sprawl consumes capacity
• No environment groups — managing 50+ environments individually instead of as governed collections

Related Skills

• alm — CI/CD pipelines, solution promotion across environments
• governance — DLP policies, tenant settings applied per environment
• licensing — Managed Environment licensing requirements
• security — Security roles and access control per environment