When an Employee Leaves, Which Automations Break?

When someone leaves, the automations that break are the ones holding a credential that carries that person's identity, and they do not all break at the same moment or in the same direction. A Gmail-scoped connection dies the instant IT resets the password, which may be weeks before the last day. A Slack bot token keeps running forever. A HubSpot private app token, which everyone treats as a service credential, starts returning USER_DOES_NOT_HAVE_PERMISSIONS on some calls and not others. And the ownership transfer you run to clean all this up rewrites the webhook URL on every Zap that catches hooks, so the fix takes down a second set of integrations that were working fine.

The usual advice stops at "use a service account." That is correct and it is not enough, because the identity that breaks is usually not the one on your automation platform. It is the one on the app underneath.

Which credentials actually carry a person

Here is what deactivating a user does to each credential type, as documented by each vendor as of August 2026.

Credential	Whose identity it carries	What deactivation does	How you find out
Google OAuth with Gmail scopes	The employee	Tokens revoked on password change, before anyone touches the account	An auth error on a date nobody links to the departure
Microsoft 365 OAuth	The employee	Disabling the account and revoking sessions stops new tokens; existing access tokens live out their hour	Runs keep succeeding for up to an hour, then stop
Slack user token	The employee	Revoked with the account	Immediate authentication failure
Slack bot token	The app	Nothing, unless every collaborator on an internal app is gone	Nothing, which is the problem
HubSpot private app token	The creating user	Some calls start failing with a permissions result, others keep working	Partial, intermittent failure
Zapier shared app connection	The employee's app account	Keeps working while that app account exists	Nothing
Zapier private app connection	The employee	Expires in 30 days, or runs until the app's own schedule kills it, your choice at removal	A cliff a month later
Make connection	The employee's app account	The connection object belongs to the team; the credential inside still belongs to the person	Nothing

Read the fourth column, not the third. Two of these fail loudly, three fail silently, and one fails intermittently in a way that looks like a rate limit. The silent ones are worse. An automation still running as a former employee's identity is writing that person's name into audit logs at every system it touches, and it inherits whatever record-level access they had, which is now nobody's responsibility to review.

The credential that looks like a service account and is not

The standard fix for personal OAuth is to swap it for a static token from a private app, on the theory that a token is a machine thing and OAuth is a person thing. HubSpot documents otherwise. If you remove the user who created a private app, some API calls that previously used that app's access token fail with a result of USER_DOES_NOT_HAVE_PERMISSIONS. The suggested remedies are to rotate the access token, or, if the removal was a mistake, to add the user back.

Two details make this worse than a plain expiry. First, private app tokens do not expire on their own, so nothing in the normal course of operations ever prompts you to look at them. HubSpot's own recommendation is to rotate every six months, which is a calendar reminder, not a system behavior. Second, the failure is partial. The token still authenticates. It just cannot do everything it could yesterday, so you get a scenario where the contact sync works and the deal update does not, which reads like a broken field mapping rather than an identity problem.

Slack goes the other way and is worth holding up as the contrast. Slack states that when member accounts are deactivated, API tokens are revoked as well, and user-specific permissions granted by that member are no longer available. But bot users, slash commands, and incoming webhooks remain active, because those belong to the app. A bot token genuinely is app-scoped. So the rule is not "static tokens are safe and OAuth is risky." It is per vendor, and you have to check.

If you are already handling credentials this loosely, it is worth reading how connections die for reasons that have nothing to do with people as well, because the two failure classes get confused constantly in triage.

The outage usually starts with a password reset

This is the part that breaks the story people tell themselves about offboarding. Google's admin documentation is explicit: third-party mail apps, "as well as other applications that use mail scopes to access a user's mail," stop syncing data upon password reset. Both access and refresh tokens go. Apps Script is exempted, and so is Android account sync when the change is initiated from the device, but a workflow platform reading a mailbox through the Gmail API is squarely inside the policy.

Password resets do not wait for offboarding. They happen after a phishing scare, on a policy cycle, when someone locks themselves out on a Monday. So a connection built on an employee's Gmail scope has a random expiry date that nobody schedules and nobody announces. When it fires, the automation fails weeks away from any departure, and the failure gets logged as a connector problem.

Microsoft fails in the opposite direction, which is equally awkward. Microsoft documents that after disabling the account and revoking sessions, the user cannot obtain new tokens, but applications using access tokens keep working until the token expires, and access tokens issued by Entra ID last one hour by default. So a Microsoft-backed automation runs successfully for up to an hour after the account is off. If your validation step is "we disabled Dave, and the invoice flow ran fine," you validated nothing.

One fails early and looks unrelated. One fails late and looks fine. Neither lands on the day you would think to check.

Transferring ownership fixes one thing and breaks another

When you remove someone from a Zapier Team or Enterprise account, ownership of all their shared and unshared Zaps transfers to a user you pick during removal, defaulting to the account owner, and the Zaps keep their on or off status. That is the good part. Shared app connections continue working as long as the underlying app account exists. Private connections are your call: expire them 30 days after removal, or let them run until the app's own expiration schedule ends them.

Then there is the line that turns a clean offboarding into a two-week mystery. Zapier documents that the webhook URL in any Zap using Catch Hook or Catch Raw Hook triggers will change when the Zap is transferred, because the URL is tied to the owner, and you must update every external app where you entered that URL.

Think about where those URLs live. A form builder's settings page. A payment processor's webhook console. A vendor portal somebody configured in 2024. A partner's system that you have to email to change. Every one of them keeps posting to the old address, receives no error worth escalating, and your Zap simply never fires. There is no failed run to find, because there is no run. This is the exact shape of failure that argues for a heartbeat on every scheduled and triggered flow rather than relying on error notifications, which only fire when something actually executed.

n8n has a narrower version of the same trap. Workflows and credentials belong to a user or a project, owners can move them, and moving a workflow or credential removes all existing sharing, which can quietly break other workflows that were relying on that share. The workflow owner also cannot be changed except when the user is deleted, so the ownership decision effectively gets made at exit under time pressure. Owning things in a project from day one costs nothing and removes the whole event.

Make is the mildest case. All users in a team can use and manage any connection created in that team, so nothing is orphaned when a member goes. The credential inside the connection still authenticates as one person's Google or CRM account, so the app-side problem is untouched.

The offboarding runbook for automations

Order matters here more than content. Several of these steps are impossible or expensive once the account is suspended.

1. Export the connection inventory before IT touches the account. One row per credential: which platform, who owns it, which app account it authenticates as, and which workflows use it. Zapier's app connections page, Make's team connections, and n8n's credentials list all give you this in a few minutes.
2. Classify each row using the table above. You are sorting into three buckets: dies immediately, keeps running as a ghost, and fails partially. The second bucket is the compliance work and the first is the outage work.
3. Re-authorize in place before the password changes. For anything where the underlying app supports a non-personal account, reconnect it to that account while the departing user can still complete the OAuth prompt or hand over the session. This is the cheapest fix and the window closes first.
4. List every inbound webhook URL before you transfer anything. For each Catch Hook trigger, write down the external system that posts to it and who can change that setting. Then transfer, then update all of them in the same sitting.
5. Rotate the tokens that never expire, on purpose. HubSpot private apps, static API keys, anything you generated once and pasted. Nothing in the system will remind you, and these are the credentials a former employee may still have in a password manager.
6. Put the automation inventory in the HR offboarding checklist, not in your automation docs. The checklist that actually gets run is the one HR runs. If the step lives anywhere else, it gets skipped.
7. Add a cheap authenticated read as a scheduled heartbeat for each remaining connection, so the next departure surfaces as an alert instead of a gap someone finds in a report.

Where to start this week

Do step one now, without waiting for anyone to resign. Open your automation platform, list every credential with its owner and the app account behind it, and mark each row with what happens when that person is deactivated. Most teams doing this for the first time find two things they did not expect: a handful of production flows running on a founder's personal Google account, and at least one connection belonging to somebody who left months ago and is still writing to the CRM.

That inventory is also the input to a real fix. If a connection cannot be moved off a personal identity because the vendor does not support one, that is a design constraint to route around, not a policy to write. We build automation systems with the credential owner decided up front and documented next to the flow, and we treat the visibility layer that tells you a connection went quiet as part of the build rather than something added after the first outage. If you want a second pair of eyes on an inventory you already ran, send it over and we will tell you which rows are the ones to fix first.