Low-Code Governance: Stopping Power Platform Sprawl Early

Every organisation I walk into with Microsoft 365 already has a Power Platform estate, whether anyone signed off on it or not. Hundreds of flows, a scatter of canvas apps, a few Dataverse tables someone stood up to dodge a spreadsheet. Leadership calls it shadow IT and wants it shut down. I take a different view. If your staff built a hundred automations without asking, your central IT was too slow to help them, and they solved their own problem. That is initiative, not misbehaviour. The job of governance is to keep that speed and strip out the risk, not to punish the people who moved first.

Shadow IT is a symptom, not a crime

A finance analyst who builds a Power Automate flow to reconcile two reports at midnight is not being reckless. She is doing in an afternoon what a change request would take six weeks to deliver. The flow works. It saves real hours. The problem is not that she built it. The problem is that nobody knows it exists, nobody owns it if she leaves, and it holds a connection to a system that finance genuinely cares about.

So the first move in any governance programme is a mindset shift. Stop asking "how do we stop people building?" and start asking "how do we make it safe for people to keep building?" Those are completely different questions and they lead to completely different controls. The first leads to lockdown, which drives the building further underground into personal accounts and unmanaged tenants. The second leads to guardrails, which keep the value on the platform where you can see it.

The rest of this framework is the machinery that turns that principle into something real: an environment strategy, data loss prevention that varies by risk, a tiering model, a fix for the single most common production incident, and the five artefacts that separate a working centre of excellence from a slide deck.

Design the environment path

The single most important control in Power Platform is not a policy document. It is your environment strategy. Environments are the boundary that everything else hangs off, DLP policies, capacity, access, and the promotion path from a rough idea to something the business depends on. Get this wrong and no amount of process will save you.

I run three tiers of environment, each with its own rules, and a deliberate promotion gate between them. An automation earns its way up. It does not start at the top.

The promotion gate is the whole point. Moving from personal to departmental means a named human agrees to own it. Moving from departmental to managed production means it gets packaged as a solution, handed to a service principal, and put behind a deployment pipeline. Nothing lands in production because someone was clever on a Friday. It lands there because it passed through two gates that each demanded something in return. I unpack the pipeline mechanics for the analytics side of this in my note on Power BI workspace structure and pipelines, and the same discipline applies here.

DLP policies by environment tier

Data loss prevention in Power Platform works by sorting connectors into groups. Anything in the Business group can only share data with other Business connectors, and never with anything in the Blocked group. The mistake most teams make is writing one DLP policy for the whole tenant, which forces them to choose between locking down the connectors casual builders need and allowing connectors that have no business touching sensitive data. You do not have to choose. You set DLP per environment tier, so the freedom matches the risk.

The pattern reads clearly across the row. The personal tier blocks anything that could exfiltrate corporate data to a consumer service or reach into a production database, but leaves social and productivity connectors open so people can build harmless helpers. The departmental tier opens up Dataverse and internal data sources because there is now a named owner, and it blocks consumer connectors that have no place in team automation. The managed tier is the strictest, allowing custom and outbound connectors only after review, because that is where the automations touching real systems live. Microsoft's own reference on data loss prevention policies covers the connector classification mechanics in full.

The tiering model that works

Environments are the container. Tiering is how you decide how much ceremony each individual app or flow deserves. The model that has held up across every estate I have governed is deliberately simple, because a model nobody remembers is a model nobody applies. Three tiers, one question each.

Tier 3: anything one person uses.

A flow that files one person's email, an app that tracks one person's tasks. If it breaks, one person is inconvenienced for an afternoon. Requirements are almost nothing. Build it, run it, no documentation, no formal owner beyond the builder, no support commitment. This is where you want most of your estate to live, because this is where speed pays off with zero risk. Do not govern it beyond the DLP guardrail. My wider view on how this maturity develops sits in the automation maturity model.

Tier 2: anything a team depends on.

A flow that routes a whole department's approvals, an app the operations team opens every morning. If it breaks, a team is blocked. Now you need requirements: a named owner who is not the sole builder, a one-page description of what it does and what it connects to, and a backup builder who can fix it. It lives in a departmental environment. It does not need a change board, but it does need to be knowable.

Tier 1: anything that touches finance, safety, or a customer SLA.

A flow that posts journal entries, an app that logs a safety inspection, an automation that a client contract depends on. If it breaks, money moves wrongly, someone gets hurt, or you breach an SLA. This tier earns full treatment: solution packaging, a service principal owner, a deployment pipeline, documented recovery steps, and a real support commitment with someone accountable. It lives in managed production and nowhere else.

The leaver problem

If you take one operational lesson from this article, take this one. The single most common production incident in a low-code estate is not a bug. It is a leaver. Someone builds a flow, owns it personally, and then leaves the company. Their account is disabled by the offboarding process, and every flow and app they personally owned stops running. In a mature estate that means a finance reconciliation silently fails, an approval queue stalls, or a customer-facing automation goes dark, and the first anyone hears of it is when the downstream breaks days later.

This happens because Power Platform lets an individual be the owner of a production automation. Personal ownership is fine for tier 3, where the builder leaving and the flow stopping are the same event and nobody else cares. It is a live grenade for anything a team or the business depends on.

The fix: service principal ownership.

For anything tier 2 and above, the owner should not be a person. It should be a service principal, an application identity in Entra ID that no human logs in as and that offboarding never touches. The pattern is straightforward:

• Register an application in Entra ID to act as the automation owner for a given environment or solution.
• Package tier 1 and tier 2 automations as Power Platform solutions rather than loose flows.
• Set the connection references and the flow ownership to the service principal, not to the builder's account.
• Give the human team co-ownership or maker access so they can edit, while the run identity stays with the principal.
• Manage the principal's credential centrally, rotate it on a schedule, and store it in Key Vault.

Now when a builder leaves, their account disables, and the automation keeps running because the identity that runs it never belonged to them. You have decoupled who built it from what keeps it alive. This one pattern removes the most frequent cause of production incidents I see in low-code estates, and it costs you one application registration per environment.

A centre of excellence without an owner is a slide

Every governance programme reaches the point where someone proposes a Centre of Excellence. Good idea, usually implemented as a PowerPoint. A CoE with no named owner and no standing monthly review is not a control. It is a diagram of one. Controls are things that happen on a schedule whether or not anyone feels like it. A CoE only becomes real when it produces artefacts that people use, and when a specific human is accountable for keeping them current.

Microsoft ships a strong starting point in the Power Platform Center of Excellence toolkit , which gives you the inventory tooling to see the whole estate. Tooling is necessary but not sufficient. Here are the five artefacts that turn a CoE from a slide into a working control.

1. A live inventory. Every app, flow, environment, and connector, with owner, tier, and last-run date, refreshed automatically. If you cannot see the estate, you are not governing it.
2. An environment and DLP policy document. The tiers, the promotion gates, and the connector classifications from the table above, written down and version controlled so decisions are not folklore.
3. An ownership register with service principal mapping. Which tier 1 and tier 2 automations run under which principal, who the accountable human owner is, and who the backup builder is.
4. A maker onboarding guide. The safe path made easy: which environment to build in, what earns promotion, and where to ask for help. This is how you keep people on the platform instead of driving them underground.
5. A monthly review with a named owner. One person accountable for running a standing session that reviews new tier 1 automations, orphaned apps, DLP exceptions, and re-tiering flags. No owner and no cadence means no control.

Miss any one of these and the CoE degrades back into a slide. The inventory goes stale, the ownership register drifts from reality, and six months later you are back to leavers taking flows down with them. The artefacts are cheap. The discipline of maintaining them is the actual work. This same "named owner plus cadence" logic underpins how I structure the analytics platform too, which I cover in Fabric governance and workspace design.

Bringing it together

Power Platform sprawl is what happens when capable people are handed a fast tool and a slow IT function. The answer is not to take the tool away. It is to build a path that keeps the speed where the risk is low and adds control only where the stakes justify it: three environments with promotion gates, DLP that varies by tier, a three-question tiering model, service principal ownership to survive leavers, and a CoE that is real because it has five artefacts and a named owner. Do those, and the estate stops being a liability and starts being the asset it always could have been.

A note on independence: I am not reselling Power Platform licences and I have no vendor incentive here. My interest is an estate that is safe to run and cheap to maintain. Where a low-code automation is the wrong tool, I will say so, and sometimes the honest answer is that a proper integration belongs in a supported service, not a citizen-built flow.