Every flow has a personal owner
A Power Automate flow belongs to whoever clicked New, and that one design decision generates most of the operational debt I find in a mature Power Platform tenant. The owner field holds a user principal name. The connections underneath it hold that person's tokens. Nothing in the product ever asks which team owns the business process the flow is running.
I have run that inventory for about a dozen clients now and the shape repeats. A tenant with 4,000 users carries somewhere north of 12,000 flows, most of them personal conveniences nobody else depends on. A few hundred sit inside real processes, and almost none of those carry a name anyone outside the maker's team would recognise.
The exposure lives in the connection rather than the flow definition. A flow writing to a SharePoint library runs under a connection the maker authorised, so every file it creates carries their identity. Rotate their password, revoke the token, or move them into a stricter conditional access policy and the flow stops. The logic survives intact. The credential behind it does not.
How a flow dies quietly
Power Automate does try to tell someone. When a flow fails repeatedly the platform turns it off and emails the owner, and a flow with no successful runs for a long stretch can be suspended too. Every one of those notices goes to the owner's mailbox. If that person left in March and the mailbox was deleted six months later, the warning arrives nowhere.
The one I still think about was an invoice coding flow at a distribution company with about 900 staff. It pulled PDF attachments from a shared mailbox, wrote a Dataverse row, and kicked off a two-stage approval. It ran cleanly for two years. Then the finance analyst who built it resigned, IT disabled her account on a Friday afternoon, and the flow failed every run across the weekend.
The failure surfaced 11 days later on a supplier chase call. Around 300 invoices were sitting unread in a mailbox nobody was watching, and the fix needed a global admin to reassign the flow and then rebuild three connections by hand. You cannot inherit somebody else's personal connection. You can only replace it.
The process that lived in a contractor's environment
The worse version is the flow you cannot find. Default environment sprawl gets all the attention, but the thing that has cost my clients the most time is a developer environment spun up by a contractor under a guest account, holding a process the business firmly believes IT runs.
A logistics client had a carrier booking process with an internal support alias and a line in the service catalogue. Everyone assumed the integration team owned it. It was two flows and a model-driven app in a developer environment belonging to a contractor whose engagement ended 14 months earlier, and his guest account was still active because disabling it had broken something once and the ticket closed as will not fix. Deciding which environments exist and who owns each one would have surfaced that years earlier, and so would paying attention to an app that outgrew the person who built it.
Developer environments cost nothing to create and stay invisible to most governance reporting. That is the design, and it works fine right up until the person who created one leaves and takes the only admin role with them.
Service accounts and solutions are the boring fix
Any flow a business process depends on should run under a service account, sit inside a solution, and live in a shared environment with a named owning team. That is my position and I will defend it in a design review. The objections are licence cost and friction, and both objections are fair.
A service account needs its own Power Automate licence, often a mailbox, and an exemption from the password rotation and MFA rules that would otherwise kill it. Security teams hate that, correctly. The compromise I push is a small set of them, one per owning team rather than one per flow, credentials in the privileged access vault, reviewed quarterly.
Solution awareness matters more than most makers expect. A solution-aware flow uses connection references and environment variables, so the credential becomes a separate object you can repoint without opening the logic. It also lets the flow move between environments through a deployment pipeline. Pipelines that people actually use are the other half of this, because a flow you cannot deploy is a flow somebody will edit in production.
An ownership register that names a human and a team
The owner field in the platform is a system value that points at exactly one account. What you need beside it is a register naming the business process, the team accountable for it, the person currently holding it, the environment it runs in, and what breaks if it stops for a day. Five columns. That is the entire artefact.
I keep it in a Dataverse table rather than a spreadsheet, because the spreadsheet goes stale in about five months and nobody notices. Forty entries usually covers the flows that matter in a mid-sized tenant. Everything else stays unregistered and unsupported, and saying that out loud in the platform review is half the value.
The register only earns its keep if the team column points at a security group that really exists in Entra and the person column carries a review date. A process with no named team gives you nobody to call at seven in the morning. An account with no team behind it gives you nobody at all, which is where automation owners lose the thread.
The leaver process has to reach the tenant
Most joiners, movers and leavers runbooks stop at the identity layer. Disable the account, reclaim the licences, forward the mailbox, close the ticket. Nothing in that sequence asks the Power Platform admin API what the person owned, and the platform will not volunteer it.
The step I add is small. Before the account is disabled, the leaver ticket fires a query for flows, apps and custom connectors owned by that user, and anything with a registered business process becomes a reassignment task on the owning team with a due date ahead of the last working day. The CoE Starter Kit inventory handles this if you run it. A scheduled admin API call handles it if you do not. Skipping the step is how the leaver handover quietly fails.
The retrofit usually waits for a loud failure
I would love to say clients do this work early. In practice it gets funded the week after a payroll file fails to post or a customer onboarding flow stops during a month end close. Converting 60 non-solution flows into solution-aware ones is genuinely unpleasant, because every connection reference has to be rebuilt, approval flows are awkward to test outside production, and a fair number of the original makers left years ago.
Budget about three days per flow for anything with more than a dozen actions, and do not promise a big bang. The sequence that has worked for me runs inventory first, then registration of the top 40 processes, then service account migration for those, then the leaver step, then the long tail whenever a flow next needs a change anyway. Keeping low-code governance light enough that people still ship is the constraint that stops this becoming a two year programme nobody finishes.
Before your next platform review, pull the list of flows whose owner is a disabled account. Take the ten with the highest run count into the meeting and ask one question about each of them. If this stopped tonight, who would notice, and how long would it take them to find out?
