Power Platform Administration Step By Step Which one when · Explained

Power Platform Environment Strategy: 4 Layers That Scale

Four layers of environments, dev-test-prod with pipelines, groups and routing, naming and ownership rules, and the 2026 developer environment deadlines.

· 5 min read

Four environment layers: Default, personal developer, team dev/test/prod, shared platform
Watch the lesson: Power Platform Environment Strategy for Enterprises (2026) | Power Platform Admin

Every Power Platform tenant starts the same way: everyone builds in the Default environment, and a year later nobody knows which app is critical, who owns it, or where its data lives. An environment strategy prevents that.

Four layers

Four layers: Default for personal productivity, personal developer environments, team dev/test/prod, shared platform
The four layers of an enterprise tenant.
  1. Default: personal productivity only, small personal apps and flows.
  2. Personal developer environments: one per maker, managed, where people learn and build.
  3. Dev, test and production for each business unit, or each important app.
  4. Shared platform environments: integration, the centre of excellence, shared data.

Dev, test, production

Dev builds in unmanaged solutions, test tests the managed solution, production runs only managed solutions deployed by pipeline
For anything the business depends on: three environments.
  • Dev: makers build in unmanaged solutions.
  • Test: the managed solution is tested by real users.
  • Production: only managed solutions, deployed by a pipeline, never edited by hand.

From October 2026, pipelines need managed target environments.

Groups, rules and routing

Do not configure fifty environments one by one. Group them by business unit or tier, such as Finance, Personal developer or Production. Rules set on the group flow down: sharing limits, connector policies, backup retention, AI features. Environment routing puts every new maker straight into a personal developer environment inside a group, already governed.

Every environment, the same four facts

  • A name that says who and what: company, unit, purpose and stage.
  • Two named owners: one from the business, one technical.
  • A security group on every production and sandbox environment.
  • The region where the data must live: moving it later is a project.

Who may create environments

Production and sandbox: admins only on request; trial: admins only; developer: everyone through routing
Restrict creation, and route makers to governed developer environments.

The 2026 deadlines for unmanaged developer environments: none new from 15 November 2026, suspended from 15 December, deleted from 15 January 2027.

An example on one page

Pragati's strategy: Default for personal productivity, managed personal developer, dev-test-prod per unit, a platform environment
Pragati's strategy, ready to adapt.
Admin center environments list: default, sandboxes and developer environments
Pragati's tenant today: only the new lab environment is managed; the older developer environments must be converted.

The checklist

  1. The Default environment is for personal productivity only.
  2. One managed developer environment per maker, through routing.
  3. Dev, test and production for what the business depends on, with pipelines to managed targets.
  4. Groups carry the rules; every environment has a name, owners, a security group and a region.
  5. Restrict who creates environments, and review the list every quarter.

Do it yourself

Lab guides, practice and full mock exams come with a subscription. See the plans