SharePoint & Microsoft 365

A Team Leader's Guide to Power Platform Environments

Choose Developer, Sandbox and Production environments for Power Platform work, with current role, licensing, isolation and promotion boundaries.

Collab365 Team · 30 March 2026 · Updated 24 August 2026 · 3 min read

Give makers a safe place to build, but do not confuse isolation with production readiness. Power Platform environments separate apps, flows, connections and optional Dataverse databases. Your team still needs roles, data policies, solution-based deployment, licences and an owner for each environment.

What an environment separates

Microsoft defines a Power Platform environment as a container for business data, apps, chatbots and flows. Environments belong to a Microsoft Entra tenant and a geographic location.

Connections, gateways, flows and Dataverse databases are environment-bound. Moving an app between environments does not magically recreate every dependency.

Choose the type by purpose

Developer

A Developer environment is for individual development and test work. Microsoft's Power Apps Developer Plan is not licensed for production use.

It is useful for experimentation and isolated solution work. It is not a shared team integration environment, and security groups cannot be assigned to Developer environments.

Sandbox

A Sandbox is a non-production environment with operations such as copy and reset. Use it for shared development, integration testing or user acceptance testing when your licensing and capacity allow it.

Treat a reset or copy as a controlled admin operation. It can replace data and disrupt connected tests.

Production

Production environments are for workloads the organisation depends on. They need named owners, support, monitoring, recovery, appropriate capacity and the licences required by their apps and connectors.

Default

Every tenant has a Default environment. Microsoft describes it as intended for exploration and lightweight app development, with broad maker access for licensed users. It has limited administrative control and should not become the accidental home of critical apps.

Roles are not the whole permission model

The built-in Environment Admin role manages an environment. Environment Maker can create apps, connections, custom connectors and flows.

Microsoft also states that those roles do not automatically grant access to an environment's Dataverse database. Dataverse security roles and application sharing still matter.

Give new makers only the access they need. Do not make every developer an environment administrator.

A practical onboarding pattern

  1. Confirm the maker has the required plan and the tenant permits Developer environment creation.
  2. Give the person a Developer environment for isolated work where appropriate.
  3. Provide a solution publisher, naming rules and connection-reference pattern.
  4. Apply the organisation's data policies.
  5. Use test data with no unnecessary personal or production information.
  6. Review the solution before it enters a shared Sandbox.
  7. Test dependencies, permissions, licences and recovery in the target environment.
  8. Promote through a controlled pipeline or documented import, never by rebuilding manually in production.

Licensing and lifecycle traps

Developer Plan rights let a maker build and test premium capabilities in a Developer environment. Microsoft states that a paid plan is required for production use of premium solutions.

Developer environments can also be disabled after inactivity under Microsoft's cleanup policy. Do not store the only copy of important work there. Export solutions to source control or another governed location.

Managed Environment features have separate licensing requirements. Turning on a governance feature is not evidence that every user is licensed for it.

Check before promotion

Before moving a solution, verify:

  • all components are inside the solution;
  • connection references and environment variables are defined;
  • flows have valid owners and connections;
  • users have app, connector and data permissions;
  • data policies permit the connections;
  • target licences and capacity are available;
  • rollback and support ownership are recorded.

A successful import proves only that the package was accepted. Run end-to-end tests with the intended user role.

For practical Power Platform administration decisions, join the Power Apps Builders Space.

Sources