What happens to Power Automate flows and Zaps when an employee leaves?

Someone leaves the firm, IT disables their account on Friday, and by Tuesday new client forms are no longer reaching the CRM. Nobody connected the two events, because nobody knew the automation ran under that person's login.

The short answer: the automations usually survive for a while, then fail once the person's connections stop working. Zapier lets an owner transfer Zaps and connections when removing a member. Power Automate leaves the flow "orphaned" until an admin assigns a new owner, and the connections still need re-authorizing. Make separates users from connections, so the risk sits in any connection made with a personal login. In every tool, the fix is the same: know what each person owns before they leave, and move important automations onto firm-owned accounts.

Why automations break when people leave

Every automation logs in to your apps through a connection: a saved login or authorization for the CRM, the mailbox, the accounting system. Connections are usually created by whoever built the automation, using their own account. When that account is disabled, deleted or loses its license, the connection stops working, and so does everything that uses it.

There is a second layer: ownership. If the automation's owner disappears, there may be nobody left with the rights to edit or fix it.

Zapier: transfer on removal

Zapier handles this better than most, provided you use its removal process rather than simply disabling the person's email. According to Zapier's help article on removing members, as documented in October 2026:

• On Team and Enterprise accounts, the removed member's Zaps transfer to a user you choose, and they keep their on or off status.
• Their app connections transfer too and are renamed with the person's name as a prefix. For private connections, you choose whether they stay active for 30 days or until they expire on the app's own schedule.
• Webhook URLs change for Zaps that start with a Catch Hook trigger, because the URL is tied to the owner. Any form or app that posts to the old URL has to be updated, or those Zaps stop receiving data.
• On Team accounts, only the account owner can transfer ownership to someone else; if an admin removes the member, everything goes to the account owner.
• If the departing person is the account owner, Zapier says it cannot transfer their Zaps or connections in this way, so plan that handover separately.

Zapier also recommends reviewing the member's Zaps, transferring ownership and exporting a CSV of their Zaps and connections before removal, in its guide to safeguarding business-critical Zaps.

The catch is the 30-day window. A transferred connection still logs in as the person who left. When it expires, or when their account in the connected app is closed, it fails. Reconnect each one with a firm-owned account during that window.

Power Automate: orphaned flows

In Power Automate, a flow without a valid owner is called orphaned. Microsoft's guidance on orphaned flows explains that these flows can fail if they use connections tied to the departed user's account. Admins can find them in the Power Platform admin center (flows with no owner listed) and add a new co-owner, or use PowerShell for many flows at once.

Three details catch small firms out:

• Changing the owner only works for solution-aware flows. Microsoft's article on changing a flow's owner says a non-solution flow cannot have its owner changed in place. You either add it to a solution (if the environment has Dataverse) or recreate it by export and import, Save as, or Send a copy. Most flows built ad hoc in a Microsoft 365 tenant are non-solution flows.
• Licensing follows the owner. For scheduled and automated flows, the same article says the flow runs under the new owner's license after a change, which can take up to seven days to apply. If the flow uses premium features and the new owner has no premium license, the flow runs for 30 days and is then turned off.
• Premium flows whose owner left are flagged for licensing. Microsoft's license enforcement page lists this case and recommends assigning a license to the new owner or a Process license to the flow.

The connections still need attention after ownership is fixed. A co-owner can open the flow and re-authorize each connection with an account that will stay.

For flows that must not depend on any person, Microsoft supports a service principal (a non-human application identity) as the owner, described in the same change-owner article. It has its own request limits and licensing implications, so it suits a few critical flows rather than everything.

Make: users and connections are separate

In Make, connections are shared resources within the organization rather than private to the person who created them. Make's help article on deleting a profile notes that if a user chooses to delete their connections, every scenario using them stops working; if they keep them, others in the organization can still use them.

The risk is subtler: a connection may still authorize as the departed person's Google, Microsoft or CRM account. When IT closes that account, the connection fails even though it still appears in Make. There is no single screen that shows which person's login sits behind each connection, so check each connection used by important scenarios and replace personal ones.

An offboarding checklist for automations

Add these steps to your existing offboarding list, and do them before the account is disabled.

1. Inventory what they own. Export their Zaps, list their flows in the Power Platform admin center, and note which Make connections they created. If you keep an automation inventory, this takes minutes; if you do not, this is the moment to start one.
2. Decide what stays. Some automations were personal helpers and can be switched off. Business-critical ones get a new owner.
3. Transfer ownership to a named person or a firm-owned account, using each platform's process.
4. Reconnect every connection with a shared or service account owned by the firm, not the new owner's personal login.
5. Update webhook URLs in any form or app that posts to a transferred Zap.
6. Redirect error alerts. Failure emails often go to the original builder. Point them to a shared inbox someone checks.
7. Watch for a week. Check run history daily after the account is disabled; problems tend to appear at the next token refresh, not on day one.

Preventing the problem next time

The lasting fix is to stop tying automations to individuals:

• Build important automations under firm-owned accounts from the start, with credentials stored in the firm's password manager.
• Give every automation two people with access, a co-owner in Power Automate or shared folders in Zapier.
• Keep a one-page inventory: what each automation does, which accounts it uses, who owns it, where alerts go.
• Check licenses on any account that owns premium flows.

Our article on why Zapier automations keep breaking covers the related habits, and our comparison of Power Automate and Zapier for Microsoft 365 firms explains the licensing side. Check with your IT provider or compliance lead before creating shared or service accounts, since some firms have policies on non-personal logins.

How Flow Mesh helps

Finding automations that depend on one person is a standard part of our stack audit: we list what is running, under whose login, give each tool a verdict (keep, configure, consolidate or replace) and set out a written plan to move critical workflows onto firm-owned accounts. If you want us to rebuild and document them, we quote that in writing after the audit and do the work inside your own accounts.

Key takeaways

• Automations rarely stop the day someone leaves; they fail later, when that person's connections expire or are closed.
• Zapier transfers Zaps and connections on removal, but webhook URLs change and transferred connections still use the old login.
• In Power Automate, only solution-aware flows can change owner in place, and premium flows need a licensed owner.
• In Make, connections survive the user, but any made with a personal login will fail when that login is closed.
• Inventory, transfer and reconnect before disabling the account, and build critical automations on firm-owned accounts from the start.