Co-Owner Instead of Lone Wolf: Setting Up Co-Owners in Power Automate

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.

Why a Single Flow Owner Is a Risk

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.

What a Co-Owner in Power Automate Is Really Allowed to Do

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:

• view the flow's run history in full
• manage the properties, i.e. start, stop the flow, or update connections
• edit the definition, for example add or remove actions or conditions
• add or remove additional owners, with one exception
• delete the flow entirely

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.

Setting Up a Co-Owner: How It Works

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.

Co-Owner or Run-Only Permission? The Difference Matters

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.

How Many Co-Owners Make Sense?

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.

What a Co-Owner Doesn't Solve

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.

Checklist: Think About Co-Owners from the Start

• When creating a new flow, immediately add at least one co-owner rather than waiting until after the first incident.
• Grant run-only permission instead of co-ownership for broad usage.
• Review co-owner lists at least once a quarter and remove access that is no longer needed.
• Set up business-critical flows as solution-aware flows wherever possible, so ownership can later be transferred cleanly.
• Document responsibility: who is the primary owner, who is a co-owner, and who gets informed when this changes.

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.

Frequently Asked Questions

What can a co-owner do that the original creator can't?

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.

Can I remove a co-owner again later?

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.

What happens if the sole owner of a flow leaves the company and no co-owner was set up?

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.

Should I add many co-owners or many run-only users?

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.

Does the co-owner feature also apply to desktop flows in RPA?

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.