The invoices stopped arriving on a Tuesday. Not with an error, not with an alert - they stopped the way a clock stops, silently and without ceremony. Finance noticed on Thursday. IT got the ticket on Friday. And by the following Monday, IT had established the thing nobody in the meeting wanted to hear: there was no system to fix. The "system" was a Power Automate flow, built two years earlier by an analyst who had since moved to a different team, running under her personal account the entire time.
Nobody had touched it in two years because it never needed touching. It collected supplier invoices from a shared mailbox, filed them into SharePoint, and posted a weekly summary. Three people's jobs were shaped around the assumption that this happened. None of them knew it was a flow. One of them thought it was "something the finance system does."
I'd like to tell you I was the IT person in that story. I've been the analyst. More than once. This post is about what I should have done at the time, and what the organisation should have made normal instead of leaving it to the judgment of whoever happened to click New flow.
The department was running on a personal account
Here's what's actually happening under a flow like that. A cloud flow belongs to the person who created it. Its connections - the saved sign-ins to Outlook, SharePoint, Teams - authenticate as that person. While she's employed, licensed, and using the same password, everything hums.
The day her account is disabled, the flow becomes what Microsoft politely calls an orphaned flow waiting to happen: it may keep running for a while on cached credentials and refresh tokens, and then, days or weeks later, it fails - long enough after the cause that nobody connects the two events. A password change does a gentler version of the same thing. The failure arrives on its own schedule, disconnected from anything anyone remembers doing.
That gap between cause and effect is what makes these breakages so disorienting. The person who could explain the flow left in March. The flow died in May. The investigation starts by looking at what changed in May, and nothing did.
It worked, which is why nobody looked
The uncomfortable part isn't that the flow broke. Automations break; that's Tuesday. The uncomfortable part is that a department restructured its work around a process that formally did not exist. No documentation, no owner of record, no line in any system inventory. It wasn't hidden. It was worse than hidden - it was invisible because it was reliable.
This is the standard trajectory of citizen development, and I say that with affection because I am one. You build a thing to solve your own problem. It works. Someone else starts relying on it. You mean to write it down and never do, because writing it down would be admitting it's permanent, and it was supposed to be temporary. Two years pass. The flow is now load-bearing, and the only record of how it works is in the head of someone who now does a different job.
I've written about how a flow failing silently looks identical from the outside to a flow working fine. Ownership has the same shape. A flow with no real owner looks exactly like a flow with an owner, right up until the day the difference is the whole problem.
The day it breaks is an archaeology dig
What does the recovery actually look like? Worse than you'd hope.
Run history is kept for 28 days. If the flow has been failing quietly for longer than that, the evidence of when it started is already gone. The builder can't be asked, or can be asked but genuinely doesn't remember, because two years is a long time and she has a new job. The flow's logic has to be reconstructed action by action, and if the actions still have their default names, "Apply to each 3" tells you precisely nothing about intent.
Then there's the ownership plumbing. An admin can find the flow in the Power Platform admin center and add a co-owner, which restores the ability to edit and re-enable it. But co-owners can't modify the credentials on a connection another owner created - the new owner has to replace those connections with their own before the flow is genuinely theirs. And because the flow was built outside a solution, there's no clean package to move; it gets rebuilt or adopted in place, with all its history and quirks.
None of this is exotic. I've watched a flow run perfectly for two months and then die because of a change nobody thought was related. The difference here is that recovery time isn't measured by the size of the fix. It's measured by how long it takes to work out what the thing even was.
What should have been true from day one
Four things, none of them heavy. This is not a governance framework. It's a seatbelt.
A second owner before it mattered, not after. The day a second person starts relying on the flow is the day it needs a co-owner. Not because the co-owner will maintain it, but because the alternative is that the flow's existence depends on one person's employment status. For anything a whole team leans on, the stronger version is a service account that owns the flow and its connections, so no individual's departure touches it.
One page of writing. What it does, what it touches, who to tell when it breaks. Not a manual - a note. The test is whether an IT person who has never seen the flow could read it in two minutes and know where to start. If the note feels embarrassing to write because the flow is "just a little thing," that's the tell that it's already not.
An inventory someone actually checks. Admins can list every flow in an environment from the admin center or PowerShell, and the CoE Starter Kit will build a proper inventory with owners and connectors over time. The tooling exists. What's usually missing is anyone whose job includes looking at it.
An exit step. When someone changes teams or leaves, their flows should be on the checklist next to the laptop and the door pass. Reassign or retire, deliberately. Ownership also decides whose licence a flow consumes, and what happens when it touches a premium connector - which is where this series goes next.
The way to think about it
The question in the title has an answer, and it's the uncomfortable one: nobody owns that flow. Ownership isn't a property a flow acquires by mattering. It's a property somebody has to assign, and if nobody did, then a process a department depends on is owned by an account that might not exist next quarter.
The analyst in that story did nothing wrong. She solved a real problem with the tools in front of her, which is the entire promise of this platform. The failure was treating something load-bearing as if it were still personal - and that failure belongs to everyone who relied on it without asking what it was. If a flow's silence would make someone's Tuesday worse, it's production software. It doesn't care that it was built in an afternoon by someone who'd never heard the word "governance." It needs an owner of record, a page of documentation, and a plan for the day its builder is somewhere else.
At the end of the month I'm closing out this Power Automate series with a retrospective on what the platform is actually for. This post is the cautionary half of that argument: the tools are genuinely good, which is exactly why the things people build with them outlive the arrangements that created them.
Frequently Asked Questions
What happens to a Power Automate flow when its owner leaves the company?
The flow becomes orphaned once the owner's Microsoft Entra account is disabled or deleted. It may keep running for a while on cached credentials, then its connections start failing. An admin can find it in the Power Platform admin center and add co-owners to restore access, but someone has to know it exists first.
How do I find all the flows running in my department?
Not from a normal maker account - you only see flows you own or that were shared with you. An admin can list every flow per environment in the Power Platform admin center under Resources, or pull the full inventory with the Get-AdminFlow PowerShell cmdlet. For an ongoing view, the CoE Starter Kit builds a dashboard of flows, owners, and connectors across the tenant.
Is adding a co-owner enough to protect a flow?
It's the minimum, not the fix. Co-owners can edit, enable, and run the flow, but they can't change the credentials on a connection the original owner created. A departing owner's connections still have to be replaced before the flow is genuinely independent of them.
Should shared flows run under a service account?
For anything a team depends on, it's the cleanest answer: the flow and its connections belong to an account that never resigns. The trade-offs are real - the credentials need managing, the account needs licensing, and sign-in policies like MFA need thought. Building the flow inside a solution with connection references makes the eventual handover far less painful either way.
Why did the flow keep working for weeks after its owner left?
Cached credentials and refresh tokens stay valid for a while after an account change, so the flow runs on borrowed time. That delay is why these failures feel random: the cause happened weeks before the effect, and nothing changed on the day it finally stopped.