Count it before you try to control it

Insights

Governance on this platform is usually sold as control over what people are allowed to build. That is the wrong frame, because the estate is already built. The questions that matter are which parts of it the business now depends on, who owns those when the maker leaves, and which controls hold without anyone reading a policy. What follows is a practitioner's view of how these estates actually fail, with no figures in it that cannot be stood behind.

Most Power Platform governance work starts with the wrong question. The question asked in the room is a version of "how do we stop people building things we don't know about". The question that needs answering is "which of the things they have already built does the business now depend on, and what happens when the person who built them changes job". Those are different problems. The first produces a review board and a queue of resentful makers. The second produces an inventory, an ownership model, and a few technical controls that hold whether or not anyone reads the policy. This is about the second, and about how these estates actually fail.

You cannot govern an estate you have not enumerated, and nobody's first enumeration is complete. The platform's own admin surfaces give you most of the raw material through the admin centre, the admin PowerShell modules and the management connectors: environments, apps, flows, which connectors are in use, and who owns what.

The Centre of Excellence Starter Kit is the usual route to a real inventory and it is genuinely useful, but be clear what you are adopting: a set of solutions built on Power Platform itself, published as community-supported content rather than a supported product. Installing it means you now operate an application, with a service identity, licensing for that identity, and attention owed when it upgrades.

The platform can supply almost every field you need. The one it cannot supply is the one that matters most: what breaks if this stops. An app with four users that commits purchase orders matters more than one with four hundred that books meeting rooms, and an inventory without business criticality is a long list nobody can prioritise. So record, for each asset worth tracking:

Every tenant has one, every licensed user is a maker in it, and it is where everything lands when nobody has thought about environments yet. It therefore accumulates business-critical assets with no development path, no lifecycle, and the loosest sharing posture you have. Treat it as untrusted and transitional.

Two moves work. Make it visibly the place for throwaway work and nothing else, and give makers somewhere better to go on day one: a personal developer environment, plus departmental development, test and production environments granted without a ticket-shaped delay. There are tenant settings for routing new makers into their own environments; check what is available in your tenant rather than trusting any blog post, this one included.

Do not try to empty it in one pass. Work top down by business criticality, and accept that some assets stay because their owner has gone and nobody will claim them. Those are candidates for a controlled switch-off: notice, a window, and a documented restore path.

Blanket governance fails for a straightforward reason: the value of this platform is that someone in finance can solve their own problem on a Tuesday afternoon. Rules that turn that into a six-week intake process destroy the thing you bought. Rules loose enough to allow it are nowhere near adequate for a flow that moves money or touches personal data.

So separate the estate explicitly. Personal and small-team productivity: light touch, no promises, no support, accepted risk that it stops working. Departmental: named owner, a service identity, documented purpose, a review that actually happens. Business-critical: source control, a development and test path, a service-account owner, change control, monitoring, and a named person who answers when it breaks at an inconvenient hour.

The tiering is a promise in both directions, and that is the part organisations skip. The top tier accepts change control because it receives support, backup and a real escalation route. If it is all obligation and no service, makers keep their work in the bottom tier and stay vague about it, and your model describes an estate that does not exist.

Data loss prevention policies classify connectors into business, non-business and blocked groups, and prevent a single app or flow from combining connectors across those groups. That is essentially the whole model, and what follows from it matters.

The model reasons about connectors, not about records, fields or sensitivity labels. It will cheerfully permit a flow that reads your most sensitive table and writes every row into an approved destination, because nothing crossed the fence. It constrains the shape of a mistake, not its substance. The HTTP action and custom connectors deserve particular attention, because both convert "an approved set of endpoints" into "any endpoint the maker can reach". Custom connectors can be classified, but only if somebody classifies them as they appear, which needs an owner and a cadence rather than a policy statement.

Sequencing matters more than policy content. Policies are evaluated when something is saved and when it runs, so tightening one can break what worked yesterday. Do the inventory first, work out what a proposed policy would break, tell those owners, then enforce. A rollout that silently breaks a payroll flow costs more political capital than the policy will earn back.

That same fence is what agents now stand on. Copilot-style agents reach data through those connectors, so wherever it is thin they find it faster than people do, because exploring reach is what they are for. And the classic agent incident is not a platform failure: the agent surfaces content the user always had permission to read but would never have found. That is an underlying permissions problem being exposed, and fixing it in the agent is the wrong layer.

An app or flow runs on connections, and a connection is an authenticated link created by a person, carrying that person's access to the target system. Almost every governance failure here follows from that one fact.

A maker leaves. Their flows stop, or worse, keep running on authority nobody is reviewing. The failure notification goes to a mailbox that no longer exists. Nobody else can edit the flow, because it was never co-owned. The first sign is a downstream complaint weeks later.

So: service principals or application users for anything above the personal tier, co-ownership as a minimum rather than a nicety, and solution-aware flows using connection references and environment variables, so the connection is a deployable artefact instead of something baked in by whoever last hit save. Then add a Power Platform step to your joiner-mover-leaver process, which in most organisations does not have one. Test ownership transfer before you need it; the first attempt to reassign a business-critical flow should not happen in the week its owner resigns.

I will not quote prices. They change, they are regional, and anything specific here would be wrong within a quarter. The shape is stable, and the shape is what bites.

A premium tier gates the connectors that reach outside the Microsoft estate, on-premises systems via the gateway, and Dataverse itself. Licensing comes as per-user seats, per-app entitlements, and metered pay-as-you-go billed against a linked Azure subscription. Dataverse capacity arrives in separate pools for database, file and log, and enabling auditing eats the log pool faster than anyone expects. Per-user request allowances are irrelevant in a pilot of eight people and decisive when the same flow runs for three thousand.

The failure is predictable: the pilot succeeds on trial or developer licensing, and the production cost becomes visible once the organisation has committed. Model the licensed population and the request volume before the pilot.

Pay-as-you-go deserves its own warning. It removes the licensing blocker, which is the point, and in doing so converts an approval conversation into an unbounded monthly bill attached to whichever subscription happened to get linked. Fine when a named person sees that bill every month. Not fine by default.

When a flow fails, the platform notifies its owner. That is the default extent of it: no ticket, no ops channel, no escalation. Retry behaviour, failure branches via run-after configuration and a scope-based try-and-catch pattern all exist, but none of them exist in your estate unless a maker built them, and the maker solving their own Tuesday problem did not.

This is why the expensive failures here are rarely outages. They are a flow that stopped three weeks ago, unnoticed because the absence of an output looks exactly like a quiet period.

For anything above the personal tier, require a failure path that raises an alert where your operations function actually looks, and monitor expected output rather than absence of errors. If a process should produce between forty and sixty records on a working day and produced none, that is your signal. Run history is kept for a limited window, shorter than most audit expectations, so if you need a longer trail write it somewhere you control.

Do the inventory first, with business criticality attached, because every later decision depends on it. Then fix ownership and identity, which buys the most safety for the least political cost. Then route new work away from the default environment. Write policy last, and test each policy against the inventory before you enforce it. Treat governance-deck numbers with suspicion: there is no honest general answer to how many environments you need or what this costs at scale. If your programme cannot name the handful of assets the business would notice stopping, it is not a governance programme yet.

Talk to us about this