Power Platform governance: environments, DLP policies and maker inventory

The default environment, a space shared by everyone

Every tenant has a default environment where all licensed users can create apps and flows. It cannot be deleted, and users cannot be removed from it. In the tenants we audit, this is where most creations end up: personal flows, apps shared with the whole organisation, open connections to third-party services.

Good practice is to embrace its role as a personal productivity space, rename it explicitly, and apply the strictest data policy to it. Serious business projects should live elsewhere.

An environment strategy

A healthy organisation distinguishes at least:

• the default environment, reserved for personal productivity;
• development, test and production environments for business apps;
• possibly dedicated environments for specific departments or sensitive data.

Tenant settings let you restrict the creation of production, trial and developer environments to administrators. Without that restriction, any user can create trial environments, which often escape controls. Environment groups and Managed Environments bring centralised rules and extra governance features; their licensing terms change over time, so check the current position before building them into your plan.

Two settings usefully complete this structure. First, associate each environment that has a Dataverse database with an Entra ID security group: only its members get access, rather than every licensed user. Second, name a business owner and a technical administrator for each production environment, recorded somewhere durable. When a critical flow breaks or an app needs retiring, the first question is always the same: who owns it? Without an answer, nobody dares delete anything, and the environment grows indefinitely. Service accounts used to run business flows must also be identified, protected by Conditional Access and tied to a named owner.

Data loss prevention policies

Power Platform DLP policies are not the same as Microsoft Purview DLP: they sort connectors into three groups.

1. Business: connectors allowed to exchange data with each other (SharePoint, Outlook, Dataverse and so on);
2. Non-business: connectors that are allowed but cannot be combined with business connectors in the same app or flow;
3. Blocked: connectors that cannot be used.

A tenant-level policy sets the baseline, and environment-level policies add restrictions. New connectors should be assigned by default to the most restrictive group that fits your context. Some connectors cannot be blocked; for generic connectors such as HTTP, endpoint filtering and connector action control let you fine-tune. Custom connectors must be covered too.

Knowing who builds what

Governance starts with inventory: apps, flows, Copilot Studio agents, connections, owners and sharing scope. The Power Platform admin centre offers inventory views, and Microsoft's Center of Excellence (CoE) Starter Kit provides more comprehensive tooling. Recurring findings in our audits:

• apps shared with the whole organisation without justification;
• critical flows whose owner has left the company;
• business flows running under an employee's personal connections;
• connections to unvetted external services.

Tenant isolation also deserves a look: it prevents connections to or from other Entra ID tenants, a discreet exfiltration path.

What an audit checks

• Who can create environments, and the list of existing environments with their owners.
• DLP policies at tenant and environment level, including the one covering the default environment.
• The default classification of new connectors and the handling of custom and HTTP connectors.
• The inventory of apps, flows and agents: sharing, owners, orphaned objects.
• The tenant isolation configuration.