The short version: A flow built on one person's login keeps running until that login changes: a password reset, a removed licence or a deleted account, and it fails without warning. Move ownership to a second named owner, give the flow a connection that is not a person's, and remove no licence from a leaver until you have checked what they own.
Why the day someone leaves is the day it breaks
A cloud flow runs with a connection, and a connection is usually the builder's own sign-in to SharePoint, Outlook or Xero. When that person leaves, three separate things can stop the flow, and the offboarding checklist normally triggers all of them at once.
| What offboarding does | What breaks |
|---|---|
| Account disabled or deleted | Actions that use the leaver's connections fail, even if the flow still has another owner. Microsoft says those specific actions "might fail" and the credentials need updating |
| Password reset | OAuth connections that relied on the old sign-in stop working. Microsoft's own advice is that service principal connections do not expire when someone changes a password or leaves |
| Premium licence removed | Any flow that uses premium capability and runs under the owner's licence stops working when the licence is unassigned |
| Nobody else listed as owner | The flow is orphaned, and Microsoft's failure emails go to no one, because only owners and co-owners are sent them |
Source: Microsoft Learn, Share a cloud flow, Manage orphaned flows (the owner-leaves guidance), Support for service principal owned flows and Fix connection failures in cloud flows, read on 30 September 2026. The cost of a switched-off flow is separate: after 14 days of continuous failure Power Automate turns it off, set out in the 14-day and 90-day rules.
Ownership: what you can change and how
- Solution-aware flow. Open the flow, Details, Edit, remove the primary owner and enter the new one. The old and new owners become co-owners. A scheduled or automated flow then runs under the new owner's licence and request limits; it can take up to seven days to apply, or you can edit and save to force it. The new owner gets the run history and connection references.
- Flow outside a solution. There is no in-place change. Microsoft says the owner is part of the flow's identity, so you make a copy through export and import, Save as or Send a copy, and the new owner creates the flow from it.
- Orphaned flow. An admin can find flows with no owner in the Power Platform admin centre: pick the environment, Resources, Flows, and look for a blank Owners column, then Share the flow with a new owner. PowerShell does it in bulk.
A connection that is not a person
| Option | Good | Watch for |
|---|---|---|
| Builder's own connection | Nothing to set up | Every problem in the table above |
| Shared service account | Survives a person leaving | Microsoft does not recommend a service account whose credentials are shared, and it must be licensed correctly to avoid multiplexing |
| Service principal application user | Owns the flow and does not depend on a person; not tied to anyone's licence or password | Set up in the admin centre; it has no user licence so it runs under non-licensed user limits; non-solution flows need their connections shared with it |
| Solution flow with a connection reference | The connection is a named reference, swapped per environment without editing the flow | Someone still has to own the reference and keep the underlying connection alive |
For a firm under 20 staff the practical answer is usually a solution, a second named owner, and one connection per system that belongs to a role account or an application user rather than to an individual. The dev-and-production setup that makes connection references work is in Power Platform ALM for a small team.
The checklist
- List the flows each person owns before their last day: My flows, plus the admin centre view for shared and orphaned ones.
- Add a second owner to every flow that matters, and confirm the failure alerts go to a shared mailbox as well as the owners.
- Move the flows into a solution so ownership can be changed in place and connection references exist.
- Check the connections. For each flow, note whose sign-in every action uses, and replace personal ones with a role account or service principal.
- Check licences. If a flow uses a premium connector, confirm the new owner holds Power Automate Premium at NZ$24.30 per user per month, or that the flow has a capacity licence, before the leaver's licence is removed. Details are in what Power Automate actually costs.
- Test after the change. Run the flow once and read the run history, then check again in a week, because the ownership change can take up to seven days to apply.
- Keep the account for a while. Disable rather than delete the leaver's account until every flow has run cleanly on its new owner.
The wider version of this, an inventory of every flow and app with an owner named, is in Power Platform governance for a small business.
The same risk at the level of the whole business, not just flows, and the handover pack to ask for, is in what happens to your business software when the person who built it leaves.
Broken connections are one cause of many; the ten-minute checklist is why did my flow just stop running.
Common questions
What happens to my Power Automate flows when an employee leaves?
If the flow has another active owner it keeps running, but any action that uses the leaver's own connection can fail, and a flow that runs under their premium licence stops when that licence is removed. A flow with no owner is orphaned. Change the owner before the account is disabled.
How do I change the owner of a Power Automate flow?
For a flow in a solution, open it, choose Details, Edit, and replace the primary owner; the old and new owners then become co-owners and it can take up to seven days to apply. A flow outside a solution cannot change owner in place, so make a copy through export and import, Save as or Send a copy.
Should I use a service account for Power Automate flows?
Microsoft does not recommend a service account whose credentials are shared, and it must be licensed correctly. A service principal application user is the option Microsoft supports for flow ownership that does not depend on a person, though it runs under non-licensed user limits.
How do I find orphaned flows in my tenant?
In the Power Platform admin centre choose the environment, then Resources, then Flows, and look for flows with no owner in the Owners column. Share each one with a new owner. PowerShell cmdlets do the same in bulk for larger tenants.
Why did my flow stop when someone left even though it had another owner?
Ownership and connections are separate. The flow can have an active owner while an action still uses the leaver's connection, which fails once their account is disabled or their password changes. Replace the connection with one that does not belong to a person.
Before someone's last day
Tell me who built what. One free 30-minute call and I will list the flows at risk and who should own each. A second opinion on your existing flows is the short version.