Power Platform Governance: How to Stay in Control Without Slowing Innovation
Every organisation I work with goes through the same Power Platform journey. First, a few enthusiastic makers build useful apps and flows. Then adoption explodes. Before long, IT discovers hundreds of apps in the default environment, flows sending company data to personal Gmail accounts, and critical processes owned by people who left last year.
The answer isn’t to lock the platform down. Done well, Power Platform governance is how you say “yes” safely: makers keep their speed, and IT keeps visibility and control. This guide covers the five pillars I set up on every engagement: environments, data loss prevention, solutions, ALM, and the operating model that holds it all together.
1. Environments: give every workload the right home
Environments are containers for apps, flows, Dataverse data and connections. Each one has its own security, its own policies and its own purpose. Getting the environment strategy right is the single most important governance decision you’ll make.
- Default environment: every licensed user can make things here. That’s fine for personal productivity and experiments, but it’s the wrong place for anything business-critical.
- Developer environments: personal sandboxes where makers can learn and prototype without cluttering the default environment. With environment routing, new makers can be sent to their own developer environment automatically.
- Shared environments for real workloads: dedicated Dev, Test/UAT and Production environments for each department or solution, with controlled maker access.
My tip: agree a naming convention on day one, for example [Department]-[Purpose]-[Region], such as HR-Dev-UK or Sales-Prod-EMEA. Restrict environment creation to admins and use a simple request process. For more detail, see Power Platform environments explained.
2. Data loss prevention (DLP) policies: your safety rails
DLP policies control which connectors can be used together, so business data can’t quietly flow into consumer services. Connectors are grouped as Business, Non-business or Blocked. An app or flow can’t combine connectors from the Business and Non-business groups, and blocked connectors can’t be used at all.
- Apply a tenant-wide baseline policy that covers every environment, including new ones.
- Layer environment-specific policies on top. What’s acceptable in a developer sandbox is not always acceptable in production.
- Block high-risk connectors by default and approve exceptions through a request, rather than leaving everything open.
- Review the connector list regularly, because Microsoft adds new connectors all the time.
3. Solutions: always build inside them
Solutions are the deployment container of the Power Platform: think of them as the zip file that holds your apps, flows, tables, environment variables, connection references and custom connectors. My rule is simple: everything that matters is built in a solution, even small projects. Retrofitting a solution later is always more painful.
- Unmanaged solutions are editable and belong in development.
- Managed solutions are locked and belong in test and production. Nobody should edit production directly.
4. ALM: from prototype to production
Application lifecycle management ensures apps and flows are versioned, tested and deployed in a repeatable way. A simple, effective flow looks like this:
- Dev: build and iterate in an unmanaged solution.
- Test/UAT: deploy a managed version and validate it with real users.
- Prod: release the managed solution, then monitor usage and errors.
For tooling, start with Power Platform pipelines, which are built in and maker-friendly. Move to Azure DevOps or GitHub Actions when you need source control, approvals and automated checks. I walk through pipelines step by step in Power Platform ALM and Power Automate tips.
5. The operating model: visibility, enablement and reviews
Visibility
You can’t govern what you can’t see. The CoE Starter Kit (and the built-in governance features in Managed Environments) shows you the apps, flows, makers, connectors and orphaned resources across your tenant. I cover the setup in how to build a Power Platform Center of Excellence.
Maker enablement
Publish a short maker playbook covering naming standards, which environment to use, how to request a production environment, security basics and how to hand over ownership. Back it up with training and a community channel where makers can ask questions.
Role-based access
- Limit environment creation to admins.
- Use Entra ID security groups to control who can make in each environment.
- Make sure every production app has at least two owners.
Periodic reviews
- Audit apps, flows and connectors every quarter.
- Clean up or reassign orphaned resources when people leave.
- Revisit DLP policies as the business and the connector catalogue change.
Quick governance checklist
| Area | Minimum to have in place |
|---|---|
| Environments | Naming convention, restricted creation, separate Dev/Test/Prod for critical apps |
| DLP | Tenant-wide baseline policy plus stricter production policies |
| Solutions | All business apps and flows built in solutions, with managed solutions in production |
| ALM | Pipelines or DevOps-based deployments, with no direct editing in production |
| Visibility | CoE Starter Kit or Managed Environments reporting, reviewed monthly |
| People | Maker playbook, training, community channel, two owners per production app |
Governance isn’t about saying no. It’s about saying yes the right way: empower makers, protect your data and keep IT supporting the platform rather than chasing it.
FAQ
Should we block the default environment?
No. You can’t delete it, and blocking it frustrates users. Instead, apply a strict DLP policy to it, route new makers to developer environments, and move anything business-critical into dedicated environments.
Do we need the CoE Starter Kit if we use Managed Environments?
Managed Environments gives you useful built-in insights and controls. The CoE Starter Kit adds inventory, clean-up workflows and maker nurture processes. Many organisations use both.
How many environments do we need?
At minimum: the default environment, developer environments for makers, and Dev/Test/Prod for each critical solution or department. Avoid creating one environment per app unless there’s a clear reason.
Related reading: Power Platform licensing guide · Azure Logic Apps vs Power Automate
