Flow owner leaves the company: how to rescue orphaned Power Automate flows

When the owner of a Power Automate flow leaves the company, the standstill is only a matter of time: their connections expire, their account is deactivated, and at the latest when the account is deleted, the flows fail, often weeks later and seemingly out of nowhere. This is the most underestimated operational risk of Microsoft automation in small and medium-sized businesses, because in most cases nobody knows fully which processes depend on a single colleague's account. The good news: orphaned flows can be rescued, and with three rules it will never happen again. As of: July 2026.

Acute case: taking over an orphaned flow

As long as the account still exists, the takeover is simple: an administrator or co-owner adds another person as an owner in the flow who will continue running it. Microsoft's guide for orphaned flows also describes the harder case after the account has been deleted: the administrator finds the flow via the Power Platform admin center, assigns it to a new owner, or exports and re-imports it. Crucial afterwards: all connections in the flow must be switched to the new owner's account, because the old connections still belong to the person who has left and die with their account. Only once every action has a working connection of its own does the process run reliably again.

Why solution flows are easier to rescue

Whether the takeover turns out elegant or painful is decided by an inconspicuous fork in the road at creation time: according to Microsoft's documentation flows within a solution can be reassigned directly to a new owner or even to a service principal, whereas classic flows outside solutions cannot, there only the path via co-owners or export and re-import plus rewiring remains. For every flow that carries a business process, the rule is therefore: put it in a solution. That costs one click when creating it and saves days in an emergency.

Prevention: the three rules for SMEs

• No business-critical flow with only one owner: at least one co-owner, better a whole team. Co-owners can edit and repair the flow and take it over immediately in an emergency.
• Central processes on a service account or a service principal: Incoming invoices, approvals and similar long-running processes do not belong on a single person's account, but on a dedicated automation account with documented access, or, as a solution flow, on a service principal without password expiry.
• Offboarding checklist item automations: every offboarding checklist should include the question of which flows, connections and shared mailboxes are tied to the person. The admin center lists a user's flows, five minutes of checking can save you a surprise outage.

The hidden twin: the license question

Even if the flow has a new owner, it can still grind to a halt: if the person who left used a premium license, the flow loses its licensing basis along with them, gets throttled and is deactivated after 14 days. So the new owner also needs the matching license, or the flow switches to a process license, which is tied to the flow instead of the person. The details on this are covered in the article on the Power Automate licensing question. If you are not sure how many single-person risks are lurking in your tenant: this is exactly the kind of inventory we carry out in our Power Automate consulting, including moving critical flows onto a clean foundation.

Frequently asked questions about orphaned flows

Do flows keep running after the owner has resigned?

Initially, often yes, and that is exactly what makes the problem so treacherous: as long as the account and connections are active, the flow keeps running. It only fails once the account is deactivated or deleted or a connection requires a new sign-in. Between departure and failure there are often weeks in which nobody thinks about the flows anymore.

How do I find out which flows belong to a departing employee?

In the Power Platform admin center, administrators can view the flows per environment and go through them by owner, and for solution flows they can even change the owner directly. This check belongs in every offboarding, together with the question of shared mailboxes and connections that belong to the person.

Should flows generally run under a service account?

For central, permanent business processes, yes: a dedicated automation account or, for solution flows, a service principal decouples the process from staff changes. For personal productivity flows of individual users this would be overkill, there co-owners are enough. Important with a service account: document access, assign a license, and do not misuse it as a license-saving model for many users, that would be unauthorized multiplexing.