Your tenant has 200 flows and nobody owns them

Most small tenants end up with flows nobody owns, running on the personal login of whoever built them. The fix is three steps: an inventory you can do without buying a governance tool, a decision per flow to switch off, adopt or rebuild, and one written policy short enough that people follow it.

Power Platform doesn't come with an expiry date on what gets built in it. Someone connects Outlook or SharePoint to Power Automate, solves a real problem, then changes roles or leaves the business. The flow keeps running on their personal login until the day it doesn't, and by then the person who could explain it has gone. Most of that risk comes off with a five-minute policy and a free tenant-wide inventory, no CoE Starter Kit required.

How does a tenant fill up with flows no one owns?

Power Platform is bundled into every Microsoft 365 licence, so starting to use it needs permission from no one. Someone gets sick of manually copying leads from a form into a spreadsheet, builds a flow in an afternoon, and it works. Six months later someone else does the same thing for a different problem. Neither one goes through IT, because there usually isn't an IT department, and neither one needs to, because each flow solves something real on the day it's built.

Unowned flows are also the ones that get switched off unnoticed: the 14-day and 90-day rules that turn a flow off and the alert goes only to the owners.

Nothing in Power Platform forces a review later. A flow doesn't announce itself when the person who built it leaves, changes roles, or simply forgets it exists. It sits in an environment, running on a schedule or a trigger, until either it breaks or someone stumbles on it while looking for something else entirely. Multiply that by a few years of an organically adopted tool and two hundred flows with no owner list is the ordinary outcome of never having to register what you built.

What risks arise when a flow uses a former employee's connection?

The step-by-step version, with ownership transfer and a checklist, is in the flow that broke the day its builder left.

This is the part that bites, and it's a mechanical fact about how Power Automate is built rather than a scare story. A connection, the thing that lets a flow talk to Outlook, SharePoint, Dataverse, or a database, is tied to the identity of whoever authenticated it. The flow itself can have an owner and any number of co-owners with full rights to edit it, but none of that changes who the underlying connection belongs to. Only the person who created a connection, or someone using a connection they separately own, can fix it.

So when someone leaves and their Microsoft 365 account gets disabled, their flows don't fail on day one. If the flow was shared, other people can often still see it and run it. What breaks is the connection, and connections don't die the moment an account is disabled, they die whenever the underlying session or token is revoked, which can be immediate or can take weeks depending on the connector and the token's lifetime. The flow keeps quietly succeeding right up until that token expires, and then it starts failing with an authentication error that has no obvious link back to someone who left the business two months earlier.

If the account is deleted outright rather than disabled, it's worse in a different way: the flow becomes orphaned, meaning it has no valid owner at all. An ordinary user can no longer see it in their flow list. It's still there, still potentially running, but now only visible to someone with environment admin or global admin rights who goes looking for it specifically. A co-owner can take the flow back over and repoint its connections, but only if a co-owner was ever added in the first place, and on most flows built by one person in an afternoon, there never was one.

How can you take an inventory without buying a governance tool?

You do not need to stand up the CoE Starter Kit to find out what's running in your tenant. That kit is a useful set of Dataverse solutions and Power BI dashboards for a larger, more mature setup, but it's overkill for a firm that just wants to know what exists, and Microsoft has since folded its core inventory capability into the admin centre itself.

Three ways to get a real answer, in order of effort:

• Power Platform admin centre, Manage → Inventory. This is the fastest option and it's free with any tenant. It gives a tenant-wide, searchable list of every flow, app, and agent across every environment, including who owns each one and which connectors it uses, refreshed roughly every 15 minutes. If you have never looked at this page, start here.
• Environment → Resources → Flows. The older, per-environment view. Useful if you want to check one environment at a time, and it's where an admin can specifically surface flows that have lost a valid owner, which don't show up to anyone else.
• PowerShell, for a full export. Install the Microsoft.PowerApps.Administration.PowerShell module and run Get-AdminFlow to list every flow an admin can see across the tenant, or scope it to one environment. Get-AdminFlowOwnerRole lists who owns and co-owns a given flow, and Set-AdminFlowOwnerRole lets you add a co-owner or reassign ownership in bulk once you know what needs fixing. All of this is free, built into Microsoft's own tooling, and doesn't touch a third-party product.

Run any one of these once and you'll usually find the same pattern: a handful of flows doing real, current work, a longer tail nobody can explain, and a few tied to names that don't show up in the staff list anymore.

What to switch off, what to adopt, what to rebuild

Once you've got the list, sort it into three piles rather than trying to fix everything at once.

• Switch off: anything whose purpose no one can explain, anything clearly a leftover from testing, and anything tied to a departed staff member's connection that isn't doing recognisable, current work. Disabling a flow is reversible and costs nothing. Leaving a mystery flow running costs you the surprise later.
• Adopt: flows that are load-bearing, invoice reminders, lead routing, approval chains, but currently running on one person's personal login. Give each one a named owner and at least one co-owner, and where the connector supports it, move the connection onto a shared account built for the purpose rather than a person's own Microsoft 365 login. A departing staff member should never be a single point of failure for a process the business depends on.
• Rebuild: anything business-critical, built by someone who's gone, that no one left understands well enough to safely edit. Don't sink hours reverse-engineering nested conditions in a flow you can't fully explain to a colleague. Rebuilding with a known owner is usually faster and safer than the archaeology.

Editing rights are worth a line in that inventory too. Since coauthoring arrived, several makers can be inside one canvas app at the same time, and the feature quietly disables undo while they are, so "who was in there" becomes a question worth being able to answer.

What governance policy will a small team actually follow?

Most governance advice is written for organisations with a platform team. A five-person or twenty-person firm needs four or five rules that fit on one page and that someone will remember to do.

1. Every new flow gets a named co-owner at the point it's built, not added later once someone remembers.
2. Anything business-critical runs on a shared connection, not a personal login, wherever the connector allows it.
3. Offboarding checklists get one extra line: check the admin centre Inventory for flows owned by this person, before the account is disabled.
4. Someone spends ten minutes twice a year scanning the Inventory list for flows with no clear owner or purpose, and switches off anything that can't be explained.
5. Every flow that matters gets one sentence of documentation, wherever the team already keeps notes.

Run the inventory once, sort the three piles, write the rules down. That is the whole project. If your Power Platform footprint has grown past the point where you can name every flow off the top of your head, that's the sign to do it this quarter rather than the next one. I cover the wider picture of what a well-run Power Platform and Copilot agent setup looks like if you want the mechanics beyond governance specifically. The same drift shows up in SharePoint lists no one has revisited in years, so if a list is what's crept up on you, where SharePoint lists actually hit their ceilings covers that side of it. And once you have the list of what exists, Power BI against Excel for job profitability is a useful read on which of those hand-built monthly reports should be a report at all.

The same risk at the level of the whole business, not just flows, and the handover pack to ask for, is in what happens to your business software when the person who built it leaves.

Who can build and administer, as opposed to who can see which rows, is in Environment Maker, System Admin or Power Platform Admin: what to give a contractor.

Common questions