Governance is usually presented as a policy document. In practice, for Power Platform, it is four operational decisions: where things get built (environments), which connectors can be combined (data loss prevention policies), who is accountable for each app and flow (named owners), and how things get switched off (decommissioning). Get those four right and the policy document mostly writes itself. Skip them and no document will save you.
Why this matters at 50–500 people
Power Platform is switched on in most Microsoft 365 tenants by default. That is a strength — staff can automate their own work without a project — and it is also how estates get messy. Within a year or two of people discovering Power Automate, a typical organisation has flows nobody remembers building, running under accounts of people who may have left, connected to systems IT did not know were connected.
None of that is malicious. It is what happens when a capable tool has no boundaries. Governance is the set of boundaries, and at this size it should be light enough that one person can run it in a few hours a month.
- 01Someone builds a useful flowin the default environment, under their own account
- 02Others start relying on itnobody writes down that it exists
- 03The builder changes role or leavestheir account is disabled, connections break
- 04The flow fails quietlyor keeps running, and nobody knows what it touches
- 05Someone notices weeks laterusually because an invoice or approval went missing
- 06Governed versionnamed owner, service connection, failure alert, offboarding step
1. Environment strategy
By default, everyone builds in the default environment, which everyone can see. Three environments fixes most of it:
- Development — where things get built and broken
- Test — where someone other than the builder tries it
- Production — where the business relies on it, and nobody edits live
If you have one environment, you have no rollback.
Leave the default environment for personal productivity — someone automating their own inbox — and make it clear that anything other people depend on moves to production through a proper path. Microsoft lets you rename the default environment; calling it something like "Personal productivity" does a surprising amount of the explaining for you.
Build business apps and flows inside solutions so they can be exported from development and imported into test and production as a package. That export is also your backup and your proof of ownership: the solution file is the build, and it lives in your tenant, not with whoever made it. We cover what to hand over in the handover documentation checklist.
| One environment | Three environments | |
|---|---|---|
| Where changes happen | Live, while people use it | Development, then promoted |
| Testing | By the builder, if at all | By someone else, before release |
| Rollback | Not really possible | Re-import the previous solution |
| Who can see work in progress | Everyone in the tenant | Only the people building it |
| Effort to run | None until something breaks | A little, every release |
2. Data loss prevention policies
DLP policies control which connectors can be combined. Without them, a well-meaning staff member can build a flow that copies customer data to a personal cloud account — not maliciously, just because the connector was there.
Set the boundary once: business connectors here, personal connectors there, never joined.
In the Power Platform admin centre, a DLP policy sorts connectors into three groups: business, non-business, and blocked. A single app or flow cannot combine connectors from the business and non-business groups. In practice that means SharePoint, Outlook, Teams, Dataverse and your line-of-business systems go in business; personal storage, consumer social media and similar go in non-business or blocked.
Expect a few flows to break when you apply it. That is the point — each one is a conversation about whether that data should have been leaving. Test against existing flows first so you can warn their owners.
3. A named owner per app and flow
The single highest-value governance act. Every flow has one person accountable for it. When it breaks at 6am, someone knows who to call. When they leave, ownership transfers as part of offboarding.
Orphaned flows are how automation estates rot.
Ownership has three practical parts:
- A named business owner — the person who decides what the flow should do and is told when it fails. Not IT, unless it is an IT process.
- A co-owner — so a single absence does not leave it unmanaged. Power Automate lets you add co-owners to a cloud flow; use it.
- Connections that do not depend on one person — for flows the business relies on, run connections under a dedicated service account so a staff departure does not quietly break them.
Then add one line to your offboarding checklist: "Transfer ownership of any apps and flows this person owns." Without that line, every resignation is a small risk to your automation.
4. A decommissioning path
Nobody plans for turning things off, so nothing ever gets turned off. Review quarterly: what has not run in ninety days? What has an owner who has left? Turn it off, watch for a week, delete it.
- Week 1Export the inventory of apps and flows from the admin centre
- Week 1Flag anything with no runs in ninety days or an owner who has left
- Week 2Ask each flagged item's owner or manager: keep, transfer or retire?
- Week 2Turn off the retirements and note the date
- Week 3Delete what nobody missed; keep the solution export on file
- Week 3Record the counts — running, transferred, retired — for the next review
The inventory is available in the Power Platform admin centre, and Microsoft's free Center of Excellence starter kit can build a fuller one if your estate is large. For most 50–500 person organisations a quarterly export and a spreadsheet review is enough; do not install tooling you will not maintain.
What good looks like
You can answer these in under a minute:
- How many flows are running in production?
- Who owns each one?
- What happens when one fails?
- What did we turn off last quarter?
If those answers take a week of emails, you do not have governance, whatever the policy says.
What it does not need to be
Governance at this size is not a centre of excellence, a steering committee, or a forty-page standard. Those make sense for organisations with thousands of makers. For you, heavy process has a cost of its own: if the only way to get a flow approved is a monthly committee, staff will build in personal accounts or reach for unsanctioned tools instead.
The aim is the opposite. Make the safe path the easy path — a clear place to build, connectors that just work within the policy, a simple way to promote something to production — and reserve the friction for the few things that genuinely carry risk. It also helps to be clear about when not to automate at all.
- Default environment renamed and reserved for personal productivity
- Separate development, test and production environments for business solutions
- Tenant-wide DLP policy separating business and non-business connectors
- Every production app and flow has a named owner and a co-owner
- Business-critical connections run under a service account
- Failure alerts go to the owner, not just the builder
- Offboarding checklist includes transferring app and flow ownership
- Quarterly review on the calendar, with a named person running it
What to do next
Start with the inventory. Open the Power Platform admin centre, list the environments and the flows in them, and try to answer the four questions above. Where you cannot, you have found your priorities — usually DLP first, then owners, then environments.
If you would rather have someone run that first review with you, governance is the core of our retainers, and our Power Automate service page explains how we set environments and ownership up as part of every build.
Governance is not a document. It is being able to answer four questions quickly.
Want the version for your business?
Work out what manual processes are costing you — three minutes, no contact details needed.
Work out the cost