Flow owner leaves the company: how to rescue orphaned Power Automate flows
When the flow owner leaves the company, automations grind to a halt: connections expire, accounts get deleted. An overview of rescue and prevention.
A single flow owner is a risk. Here's how to set up co-owners in Power Automate from the start and avoid orphaned flows.
A flow has been running reliably for months, processing invoices, sending reminders, or syncing data between two systems. It has a single owner, usually whoever originally built the flow. As long as everything runs smoothly, this never becomes an issue. The problem only appears once that exact person is on vacation, sick, or no longer with the company: nobody can edit the flow, view the run history, or fix an expired connection.
The solution is unspectacular and takes just a few minutes: add at least one co-owner, ideally right when the flow is created rather than only once things go wrong. This article explains what a co-owner in Power Automate is allowed to do according to official Microsoft documentation, how to set one up, and why this single setting prevents the scenario where a flow owner leaves the company and nobody has access anymore.
By default, Power Automate assigns every cloud flow to exactly one person: the user who created it. According to the Microsoft documentation on changing the flow owner this assignment is a fixed part of the flow's identity. Until a co-owner is added, control over the entire flow rests with a single person, including the license, connections, and permissions.
If this person leaves the company, the flow becomes what is known as an orphaned flow. Microsoft explicitly describes in the guide to handling orphaned flows that a flow without a valid owner can fail as soon as it uses connections tied to an account that no longer exists. Fixing it then requires the Power Platform admin center or PowerShell cmdlets such as Set-AdminFlowOwnerRole, which costs time that simply isn't needed if a co-owner was set up in advance. It gets even more unpleasant with a so-called non-solution-aware cloud flow: here, according to the documentation, the owner cannot be swapped directly at all, because the owner is part of the flow's identity. The only option left is the detour via export and import, or the Save As function, just to get an active owner again.
According to the guide to sharing a cloud flow a co-owner has practically the same rights as the original creator. Specifically, a co-owner can:
This one exception matters: according to the documentation, a co-owner cannot remove the original creator from the owner list. Otherwise, the rule is: full control for every co-owner. That is exactly why, according to Microsoft, this role should only go to people or groups you genuinely trust, since a co-owner can change or delete the flow just as easily as the person who built it.
Adding a co-owner takes less than a minute in practice:
1. Sign in to Power Automate and open My Flows.
2. Select the desired flow, open the three dots (⋮), and choose Share.
3. Enter the name, email address, or group name of the person who should become a co-owner.
The flow then automatically appears for the added person under Team Flows, and they can manage it from there just like a flow they created themselves. For SharePoint-connected flows, you can even set an entire SharePoint list as a co-owner: everyone with edit rights on that list then automatically gets edit rights on the flow, without individual people having to be maintained manually.
Not everyone who needs to use a flow requires the full control of a co-owner. Power Automate also offers run-only permission, which lets someone trigger the flow manually, for example via a button, without seeing the logic or viewing the run history. The guide to cloud flow sharing and permissions states the recommendation unambiguously: co-owners should only be added as needed for collaborating on a flow; in most cases, run-only permission is entirely sufficient for broad usage.
An example from the documentation makes the difference tangible: a helpdesk team has a flow that creates a ticket and sends a confirmation. Ten colleagues are meant to be able to use it. As run-only users, they can start the flow via the button, but cannot edit it, delete it, or view its history. Only someone who actually needs to work on the design or maintenance needs the co-owner role.
Every additional co-owner is effectively one more full owner. The guide therefore recommends granting co-ownership sparingly and reviewing it regularly: if, for example, a flow was shared with an external consultant or developer for troubleshooting, access should be removed again once the task is complete, unless there is an ongoing need. In practice at NordFlux, this means: two to three fixed co-owners per business-critical flow are better than a long, unmaintained list. This way you keep control over who really has access, without having to panic every time staff changes.
A co-owner cushions the risk of a single point of failure but does not replace proper governance. For truly business-critical, long-running flows, it's also worth looking at solution-aware flows: only with these can ownership, according to the documentation, be transferred cleanly and completely, including run history and connection references, and both the previous and the new owner automatically become joint owners after the transfer. With non-solution-aware flows, even with a co-owner in place, the creator always remains technically anchored in the owner circle, unless someone takes the detour via export, import, or Save As.
If you run a larger Power Automate landscape and want to bring order to governance, licenses, and ownership structures once and for all, you'll find support in NordFlux's Power Automate offering. This way, automation stays stable even through staff changes, and you always retain control over who looks after which flow.
Nothing. According to the documentation, a co-owner has the same rights as the creator, with a single restriction: they cannot remove the original creator from the owner list. Otherwise, editing, deleting, and sharing rights are identical.
Yes. On the flow's detail page, you can open editing in the Owners section, and there any owner or co-owner can remove another co-owner via the delete icon. Important: if this person used their own connections in the flow, you should check and, if necessary, update those connections afterward.
The flow becomes an orphaned flow and can fail as soon as it uses connections tied to the no-longer-active account. Administrators then have to manually assign a new co-owner in the Power Platform admin center or via PowerShell, which is considerably more effort than setting one up in advance.
In most cases, run-only users. Microsoft explicitly recommends limiting co-ownership to people who actually work on the design or maintenance of the flow, and giving everyone else who merely needs to use the flow only run access.
Yes, with its own model. For desktop flows, when sharing you explicitly choose between the User role, which only permits running it, and the Co-Owner role, which brings full editing, sharing, and deletion rights for the desktop flow. The principle is therefore the same as for cloud flows; only the naming of the permission levels differs slightly.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
When the flow owner leaves the company, automations grind to a halt: connections expire, accounts get deleted. An overview of rescue and prevention.
Instead of just Yes or No: how to set up approval flows in Power Automate with your own response options and evaluate them.
Setting up co-owners correctly is only the first step; governance does not stop there. Who decides how many co-owners make sense, who maintains naming conventions, and who takes over if a flow fails in a real emergency? NordFlux builds resilient ownership structures for your Power Automate landscape so that no single flow depends on a single person.