Skip to content

Environment Tier Decision Guide

The environment decision is the most consequential early governance decision. Get it right before solutions proliferate.

TL;DR

Match environment type to risk and purpose: Default is for admin use only — not for business solutions. Developer environments give makers isolated sandboxes. Business unit environments serve team production needs. Managed Environments add policy enforcement and monitoring. The minimum viable structure is: Default (restricted) → Developer (per maker) → Shared Development → Test → Production. Consolidate later only after the structure is proven.

Applies To

Audience: Platform Admin · CoE Lead · Solution Architect Frameworks: SCALE-OPS (Containment) · SHIELD (Harden)

The Decision Framework

Start With: What Is the Purpose?

Purpose Environment Type Notes
Personal learning and exploration Developer environment (per maker) Free with qualifying licence
Building a business solution (Tier 2) Shared maker environment or dedicated BU environment Managed recommended
Testing before production Dedicated Test / UAT environment Separate from Dev
Live business solutions Production environment Managed, backup enabled
Integration and automation (CoE) Dedicated Admin/CoE environment Isolated from business solutions
Tenant-wide admin operations Default environment (restricted) Never for business solutions

Should This Environment Be Managed?

Use Managed Environments when:

  • The environment contains production workloads
  • You need to enforce DLP policies with weekly digest
  • You want Maker Welcome content on sign-in
  • You need solution-checker enforcement at import
  • The environment has external-facing solutions or regulated data

Do not make every environment Managed — it adds licensing cost. Developer environments and low-risk shared sandboxes do not need it.

How Many Environments Do You Need?

Minimum viable structure (any organisation):

Default (restricted — no business solutions)
├── Developer environments (one per active maker)
├── Shared Development (team collaboration)
├── Test / UAT
└── Production

Extended structure (larger organisations with multiple business units):

Default (restricted)
├── Developer environments (per maker)
├── CoE / Admin environment
├── Per-BU:
│   ├── Development
│   ├── Test / UAT
│   └── Production
└── Shared services (common components, connectors)

Do not start with the extended structure unless you have the CoE maturity to manage it. Start minimum viable and expand deliberately.

How Should Environments Be Named?

Use a consistent naming convention. Recommended pattern:

[Org]-[BU/Team]-[Purpose]-[Region]

Examples:
  CONTOSO-HR-DEV-UK
  CONTOSO-FINANCE-PROD-US
  CONTOSO-COE-ADMIN
  CONTOSO-MAKER-[Username]

Naming is more important than it seems — environment names appear in DLP policies, monitoring dashboards, and audit logs. Inconsistent names make governance significantly harder.

Environment Types Quick Reference

Environment Type When to Use Managed? DLP Required?
Default Admin operations only. Restrict maker access. No Yes — most restrictive
Developer Per-maker sandbox for learning and building No Moderate
Sandbox Shared team development Yes (recommended) Yes — development tier
Production Live business solutions Yes Yes — production tier
Trial Proof of concept, time-limited No Minimal

Common Mistakes

Mistake Why It Happens Consequence
Using Default environment for business solutions Fastest path for makers No isolation, no lifecycle, hardest to govern
One production environment for all BUs Simpler to manage initially Solutions from different BUs share data and DLP scope
Developer environments shared between makers Licensing confusion Solutions owned by wrong accounts; shared sandbox is not a developer environment
No Test environment "We'll test in dev" UAT on dev breaks in-progress work
Too many environments too early "We'll need them eventually" Cannot manage what you cannot govern; environment sprawl

Next Steps