Power Platform governance in a smaller organisation comes down to three practices done consistently: keep business-critical apps and flows out of the default environment, apply a data policy so business connectors cannot be combined with consumer ones, and make sure every flow the business depends on runs on an identity that does not leave when a person does. Enterprise governance frameworks assume a Center of Excellence and a platform team you do not have. A one-page register you actually update beats a twelve-page policy nobody reads.
Most SME Power Platform estates are not governed badly. They are not governed at all, because nobody ever decided they were an estate. The real risk is rarely a compliance breach. It is that nobody knows what exists, or what quietly stops working when someone leaves.
Home / Guides / Power Platform / Power Platform Governance for SMEs
Last updated: 3 August 2026. By Matty Hatton, founder of Digital Adaption.
The pattern goes like this. Supplier statement reminders stop going out in March. Finance finds out in April, when a supplier rings about an invoice unpaid for six weeks. The flow that sent them was built eighteen months earlier by someone in purchase ledger who left in February, and when IT closed her account, exactly as the offboarding checklist said, the connection it used stopped authenticating. Nothing alerted. The first person to notice was a supplier.
That is what governance is for in a business of 30 to 300 people. Not compliance theatre. Knowing what exists, what it touches, and who is on the hook when it breaks. This guide covers environments, DLP policies with a worked example, service accounts versus personal accounts as flow owners, and a monthly review someone will actually keep doing.
Power Platform is unusual in that nobody procures it. It arrives inside Microsoft 365. No project, no steering group, no go-live. Someone in sales discovers they can build an approval flow, and eighteen months later there are forty.
Three structural facts make this worse than it sounds. Every licensed user is a maker by default: Microsoft's documentation is explicit that in the default environment all licensed users hold the environment maker role. That environment cannot be deleted, and is intended in Microsoft's words "for experimentation, exploration, and lightweight, app trial development", not for production. Production workloads land there anyway, because it is where the platform drops you. And nobody owns the estate.
The consequence is rarely a data breach. It is operational fragility: undocumented flows, several now load-bearing, all running on personal credentials.
Search for Power Platform governance and you find the Center of Excellence Starter Kit, environment strategy matrices and material on governance boards. That material is good, and written for organisations with hundreds of makers and a dedicated platform team. Applied to a 90-person business it produces a document written once and never read again. Do three things properly instead:
An environment is a container for apps, flows, connections and optionally a Dataverse database. An app can only connect to data sources in the same environment, which makes environments the primary isolation boundary. The default one is a special case.
| Characteristic | Consequence |
|---|---|
| All licensed users hold the environment maker role | You cannot restrict who builds there, only what they can build. |
| Cannot be deleted | It exists forever. Govern it rather than ignore it. |
| Intended for experimentation, not production | Business-critical apps here have no lifecycle, no dev/test split, no solution packaging. |
| Power Platform admins are no longer automatically granted the Dataverse system administrator role here | You can lock yourself out. Assign it deliberately to a few trusted users. |
Microsoft suggests renaming it to something like "Personal Productivity Environment". That sounds cosmetic. It is not. Half the reason production apps end up there is that the default name tells makers nothing, so they assume it is the company environment.
Three environments is usually right: the renamed default for personal flows and SharePoint form apps, a production environment for anything a process depends on, and a sandbox for testing changes first. Only a small named maker group builds in the latter two. Microsoft publishes a sizing heuristic based on user counts, but "does a process stop if this breaks" is a cleaner test.
Moving something out is not drag and drop: create a solution, add the app and every dependent flow and table, export, import, assign security roles, migrate configuration data, test, then remove access. Budget half a day per app. One gotcha, customising a SharePoint list form creates a canvas app in the default environment. Set-AdminPowerAppSharepointFormEnvironment designates a different one, but existing forms are not migrated and SharePoint-triggered flows still land in the default.
What most people still call DLP policies are now data policies in the Power Platform admin center, under Security then Data and privacy then Data policy. Both terms are in circulation for the same thing.
A data policy sorts every connector into Business, Non-business (where unassigned connectors land) or Blocked. The mechanism is routinely misunderstood, so state it precisely: a connector in one group cannot share data with a connector in another group inside the same app or flow. It is not a rule about what data is sensitive. It is a rule about which connectors may appear together.
Here is a class of leak a data policy genuinely prevents, and it is almost never malicious. Someone in sales wants the price list on their phone at the weekend, so they build a two-step flow: when a file is created in the Sales SharePoint library, copy it to their personal cloud storage. Four minutes, no approval needed. What now exists is a continuous automated export of commercially sensitive documents into a consumer account you cannot search, cannot apply retention to, and cannot include in a subject access request. They leave eight months later and the synced files stay.
| Group | Connectors |
|---|---|
| Business | SharePoint, OneDrive for Business, Office 365 Outlook, Office 365 Users, Microsoft Teams, Excel Online (Business), Dataverse, SQL Server, Approvals, Planner |
| Blocked | Dropbox, Box, Google Drive, Gmail, OneDrive (consumer), Outlook.com, X (Twitter), Facebook, Bitly, FTP and SFTP unless a named process needs them |
| Non-business | Everything else, pending review |
Under that policy the flow will not save, because the two connectors sit in different groups. Then set the default group for new connectors, the step people miss: Microsoft adds connectors continuously and each lands in whichever group you nominated, via Set default group. Their general advice is Non-business. For the default environment it is stronger, Blocked. That is the right setting there. I would not use it in production, where an unexpected block breaks something at 3am.
Policies are tenant-level or environment-level, and an environment-level policy cannot override a tenant-level one. That hierarchy lets you run a strict policy over the default environment and a looser one over production.
Some connectors cannot be blocked because core platform functionality depends on them, and Office 365 Outlook is one. It lets a maker send, reply to and forward mail from any mailbox they can access. Put it in Business by all means. You cannot block it. So a data policy alone will not stop a flow forwarding a shared mailbox to an external address.
The second half of the control lives in Exchange, because mail sent by a flow carries identifying SMTP headers that transport rules can act on:
x-ms-mail-application: Microsoft Power Automate; ...
x-ms-mail-operation-type: Send
x-ms-mail-environment-id: <environment GUID>The operation type distinguishes Send, Reply and Forward, and the environment ID lets you block external forwarding from the default environment while allowing it from governed production. That header is only present on Power Automate connections created after July 2020, so older flows will not carry it.
One warning on rollout. Enforcement is neither instant nor gentle. When you create or change a policy, a background job scans every active flow in the environment and suspends the ones that violate it, and Microsoft documents that enforcement as asynchronous and occurring within 24 hours. So the breakage does not necessarily land while you are watching. Inventory what is running first, and publish on a Tuesday morning rather than a Friday afternoon.
This is the highest-value point on this page. Microsoft's definition is precise: a connection is "a stored authentication credential for a connector". When Sarah in purchase ledger builds a flow and signs in to SharePoint, that credential belongs to Sarah. The flow does not act as the business. It acts as Sarah, until IT disables her account. Then it fails quietly into a run history belonging to someone who no longer exists. Microsoft puts it plainly: "When a maker leaves an organization, the maker's apps and flows are in effect owner-less."
The obvious response is a second owner on every important flow. This is the most common Power Platform governance advice on the internet and it is only half right. A co-owner can open the flow, edit it, turn it on and off. It does not change which credential the flow authenticates with. The connections are still Sarah's. Kill her account and the flow still stops.
There is a related trap. Turning a flow on requires that person to own, or have permission to use, every connection in it, and if not they get ConnectionAuthorizationFailed. Sharing your way out is harder than it looks, because OAuth connections can only be explicitly shared with a user representing a service principal, not an ordinary colleague. Once the owner has gone the fix is usually to recreate the connection, which is why this belongs before someone's last day.
The textbook answer is "use service accounts for everything". In an SME that is too expensive and too blunt: a dedicated automation identity costs a licence, and a premium one if the flow uses premium connectors. Done lazily it is worse than the problem, because a shared account with the password in a spreadsheet and MFA switched off is a risk rather than a governance win. What works at this size:
svc-automation@.The structural answer is connection references: a solution component sitting between the flow and the connection. Flows created inside a Dataverse solution bind to a connection reference rather than to a connection. To change the credential a flow runs on, edit the connection reference and every flow using it follows.
Flows created outside a solution use connections directly, and adding them to a solution afterwards does not upgrade them. Two ways to convert: export the flow in an unmanaged solution and reimport it, which replaces connections with connection references; or use the flow checker warning inside the solution, which offers an action to remove connections so connection references can be added. For ten to fifteen production flows this is a day's work, and it is the difference between a leaver being an inconvenience and an outage.
Finally, the cheapest control here, and one almost nobody has. Before disabling a leaver's account, inventory what they own in Power Platform and reassign anything the business depends on, while the account still works. Your HR process already has a step for the laptop and the door fob. Add one for automation. A Power Automate consultant should build this into handover.
Documentation fails in SMEs predictably. Someone builds a template with fifteen fields per flow, it is filled in once, and it is stale within a quarter. The test is not completeness, it is whether the person updating it will still do so in month seven. One spreadsheet, six columns: name, what it does in one line, environment, runs as (the identity the connections authenticate with, not who built it), business owner, and what breaks if it stops.
Only register things in your production environment. Try to catalogue every personal flow and the register dies. Keep it in SharePoint or Teams alongside your other operational documents, not in a Word file on the IT manager's desktop.
Elaborate naming taxonomies do not survive in small organisations. Something with three parts does:
[Area]-[Trigger]-[Outcome]
Purchasing-POApproved-NotifyGoodsIn
Sales-QuoteAccepted-CreateERPOrder
HR-NewStarter-CreateITTicketAnyone can read that in a list without opening it. Compare with what you probably have, a screen of entries called "When an item is created" and "Copy of When an item is created (2)". Apply the same discipline to connection references, whose names otherwise default to the connector plus a random suffix.
Governance that needs a meeting will not happen. Governance that is a recurring half-hour calendar entry for one named person will. Install the admin module once, noting the constraint that catches people out: it uses .NET Framework and needs Windows PowerShell 5.x, so it will not load in PowerShell 7.
# One-time setup, in Windows PowerShell 5.1
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser
Add-PowerAppsAccount
# Every flow in the tenant, to a spreadsheet you can diff month on month
Get-AdminFlow | Export-Csv -Path '.\flow-inventory.csv' -NoTypeInformation
# Stored credentials in the default environment, and who owns each
Get-AdminPowerAppEnvironment -Default |
Get-AdminPowerAppConnection |
Select-Object DisplayName, ConnectionName, CreatedBy
# Flows calling arbitrary HTTP endpoints, which sidestep connector-level policy
$default = Get-AdminPowerAppEnvironment -Default
Get-AdminFlowWithHttpAction -EnvironmentName $default.EnvironmentNameProperty names vary between module versions, so if a column comes back empty, pipe one object to Format-List *. Then five questions:
With Managed Environments licensing, the actions page surfaces some of this automatically, including apps without valid owners and apps unused for 60 days.
Dataverse for Teams environments multiply silently. One is created automatically the first time someone builds an app in a team. Admins have limited settings for them and security roles are not customisable, because membership maps to Teams membership type.
Developer environments and routing. Anyone with a Developer Plan licence can create one, though provisioning can be restricted to admins. Default environment routing is better: each new maker gets a personal developer environment instead of the shared default, placed automatically into an environment group with your rules pre-applied.
Environment groups and Managed Environments. Groups apply rules in bulk and lock them so local admins cannot override them, but they can only contain managed environments, and managed environment features need premium Power Platform licensing rather than Microsoft 365 alone. Check the guide to Power Automate licensing in the UK before assuming what you are entitled to.
Certified organisations. If you hold ISO 9001, an auditor asking how you control changes to business processes will not accept "we use Power Automate". The register, the sandbox and a note of who approved each production change is usually enough. Same discipline as segregation of duties in an ERP system, applied to a lighter tool.
ConnectionAuthorizationFailed means they lack permission on at least one connection. Either the connection owner turns it on, or the connections are recreated under the new identity.Most of the problems above share a root cause: an estate that grew without anyone accountable for it. Putting the three practices in place is what my Power Platform consultancy work covers. An environment strategy that fits your size, a data policy written against your actual connector usage rather than a template, and production flows moved onto connection references.
If the problem is narrower, a focused Power Automate consultant engagement is the right shape. For background see what a Power Automate consultant does, and for a build following the ownership pattern above, an approval flow from a shared mailbox. Where nobody agrees what the data means before it is automated, that is a data governance problem, not a Power Platform one.
The set of controls deciding where apps and flows are built, what data they may touch, and who is accountable for them. In a smaller organisation it reduces to three things: an environment strategy, a data policy stopping business connectors being combined with consumer ones, and a clear owner for every flow that matters.
No. A Center of Excellence is an operating model for organisations with hundreds of makers and a dedicated platform team. A business of 30 to 300 people needs one named owner, a data policy, an inventory spreadsheet and a thirty minute monthly review. A half-configured CoE kit is worse than a maintained spreadsheet.
Any flow a business process depends on should run on an identity that does not leave when a person does, usually a small number of shared automation identities or a service principal where the connector supports it. Personal accounts remain fine for personal flows. The detail that matters most: a connection is a stored credential belonging to whoever created it, so changing the flow's owner does not change the identity it runs as.
Not entirely. Every licensed user gets the environment maker role there and the environment cannot be deleted. You can apply a restrictive data policy, set the default connector group to Blocked, restrict who can create environments, rename it, and use environment routing to give new makers a personal developer environment instead. Aim to make it harmless rather than empty.
No. Sharing limits, usage insights, the actions page and environment groups are premium capabilities needing premium Power Platform licensing rather than Microsoft 365 alone. Data policies, environment strategy, connection references and the admin PowerShell module are available without them and cover most of the risk in a smaller estate.
If this is more than you want to take on at once, do the smallest useful version. Open the Power Platform admin center, look at the default environment, and find the flow that would cause the most damage if it stopped tomorrow. Work out which identity it runs as. If that identity is a person, fix that one thing. Then the next.
Three practices applied consistently beat a governance framework nobody reads. That is true at 30 people and still true at 300. If you would rather have someone do the inventory with you, book a 30-minute data risk call.
Matty Hatton is the founder of Digital Adaption, an ERP and data consultancy on the Wirral working with manufacturing SMEs across the North West and the UK. His delivery background includes a £4.5m programme consolidating four legacy ERP systems onto a single Infor LN cloud instance for a 220-user group over three years, and he is Microsoft PL-200 certified. Delivery is ISO 9001 certified.