Why your automation breaks when an employee leaves

Say you run a 20-person commercial cleaning company in Phoenix. Your operations manager, the one who built things, left in March. Nothing broke. Then on a Tuesday in May your largest account asks why nobody replied to the quote request sent eleven days ago.

The form works. The email still lands. What stopped is the step in the middle, which took the submission, created the deal in HubSpot, assigned it to whoever was on rota and sent the acknowledgement. It stopped because it ran on his Google login, which IT has now closed.

Your automation breaks when an employee leaves because the connection was authorised by a person rather than by your company, and that person has gone. When their account is suspended, deleted or has its password reset, the credential sitting inside your automation platform stops working, and the automation fails quietly rather than loudly. The fix is to move every connection onto an account nobody carries out of the building with them.

Here's how to find yours.

Why automation breaks when an employee leaves

The credential belongs to the person who set the automation up, not to the business paying for it.

When you connect HubSpot to Zapier, Gmail to Make or Xero to n8n, you aren't handing over a password. You're going through OAuth 2.0, the authorisation standard behind every "Sign in with Google" button. What the platform keeps at the end of that flow is a refresh token, a long-lived credential it uses to mint short-lived access tokens each time the automation runs.

That token is tied to whoever clicked Allow. Not to the company. Not to the automation.

Google's OAuth 2.0 documentation lists the ways a refresh token stops working, and several of them describe a routine offboarding: the user revokes the app's access, or the token goes unused for six months. One more catches people out. Each Google Account is capped at 100 refresh tokens per OAuth client, and once you pass that cap the oldest token is invalidated without anyone being told.

Password resets do it too. Google's admin help notes that a password change automatically revokes OAuth tokens for certain products, after which third-party mail apps stop syncing until the user signs in again. Nobody reads that line and thinks about their invoice reminder sequence.

Then there's the timing. Signing a former employee out and revoking an app's access to their data are two separate admin actions in Google Workspace. The automation often survives the last day, the handover and the leaving card. It dies three weeks later, when somebody tidies the account up properly, and by then nobody connects the two events.

Why does my automation keep asking me to reconnect the account?

Because the token behind it has been invalidated and the platform wants a human to re-authorise it.

Zapier's community forum is full of these threads, and the pattern repeats: a connection expires, someone reconnects it, days later it expires again. Reconnecting treats the symptom. If the login underneath belongs to a part-time bookkeeper whose password policy forces a change every 90 days, you have signed up for a reconnection every 90 days, forever, on every automation that touches her account.

A reconnect loop is a design problem wearing a support-ticket costume. The question isn't how to reconnect it, it's whose account this is.

What happens to our Zaps when a team member leaves?

The Zaps survive. The connections underneath them usually don't.

A Zap is a saved workflow, and removing someone from a Zapier team account doesn't delete the ones they built, which is the good news and also the reason this hides so well. The Zap sits in the list looking healthy until it runs and the app connection throws an authorisation error. Zapier publishes guidance on team transitions covering how to transfer a departing member's Zaps and app connections to another user, which is worth doing before the leaving date rather than after.

Other platforms behave the same way for the same reason. A contributor in n8n's community forum puts it plainly: deactivate the leaver's corporate account and the OAuth token is revoked, so every workflow using that credential fails. Reassigning the credential inside n8n doesn't help: that changes who manages it, not which account authorised it. Practitioners in Make's community recommend the obvious counter, which is to build connections on an email account independent of any one person from the start.

How do I find every automation running on one person's login?

Open each platform's connections page and read the account name beside every connection. That's the whole method, and it takes about half an hour for a small business.

1. Zapier shows the authorising account on the Apps page, Make under Connections, n8n under Credentials.
2. Write down every connection whose account is a named person rather than a shared or system address. Include the ones that look fine. A working connection owned by a leaver is a scheduled outage, not a success.
3. Add anything with an API key pasted into a step. Those don't expire on offboarding, which sounds better and is worse, because they keep working for someone who no longer works for you.
4. Check your Google Workspace or Microsoft 365 admin console for third-party app grants under suspended users. That's where the connections nobody remembers making turn up.
5. Sort the list by what it costs you if it fails at 6pm on a Friday, and fix in that order.

Say you run a freight forwarder in Jebel Ali with 11 staff and four automations. Two of them will be hanging off the same operations coordinator's account, because she built them. One will be using a Gmail address belonging to a contractor who finished eighteen months ago. That third one is the interesting find.

What to connect an automation with instead of a personal login

You want an identity that keeps existing after people change jobs. In practice, one of these:

• A service account. A non-human identity, meaning a credential that represents a system rather than a person, issued by the platform itself. Google Cloud and Microsoft Entra ID both support these properly, and they're the right answer wherever a vendor offers one.
• An application-level credential. HubSpot private app tokens, Stripe restricted keys, Xero custom connections. These belong to the app rather than to a seat, and they can be scoped down to the few permissions the automation actually needs.
• A shared operations mailbox with a real owner. Less elegant, works everywhere. An ops@ or automation@ address, kept in your password manager, two-factor on a shared authenticator, one named person accountable for it. Not a mailbox everyone knows the password to.
• A documented owner for each automation. Not a credential, but the thing that makes the other three survive contact with reality. One line each: what it does, which connection it uses, who to call.

That last one sounds like admin. It's the difference between a 20-minute fix and a week of archaeology. A broken connection you can't see costs more than one you can, which is the companion problem.

Can you transfer an automation's ownership instead of rebuilding it?

Sometimes, and it's worth checking first, because rebuilding is slow.

Zapier supports changing the owner of a shared Zap and of app connections inside a Team or Enterprise account, which handles the licence and the visibility. What it doesn't handle is the identity behind the connection: moving a Zap to a new owner won't change which Google account authorised Gmail. For that you re-authorise with the account you want, then point the steps at the new connection.

Half-fixed automations are where this starts doing damage rather than nothing. One that's been re-authorised twice, pointed at two connections and partly rebuilt is exactly the shape that begins creating duplicate records. Fix the identity once instead of patching around it.

Automations are getting their own identities in 2026 and 2027

The platform vendors have decided this is their problem too, and the direction is clear enough to plan around.

Palo Alto Networks' 2026 Identity Security Landscape, a vendor survey of 2,930 security leaders, puts the ratio of machine identities to human ones in the enterprise at 109 to 1, up from 82 to 1 a year earlier.

Microsoft has shipped plumbing to match. Microsoft Entra Agent ID gives AI agents their own directory identities rather than borrowing a staff member's, and Microsoft announced general availability of Agent 365 on 1 May 2026, extending the Entra controls to those identities. Google and the automation platforms are moving the same way.

For a small business the practical read is simple. Over the next year or two, the tooling for an automation that owns its own credential, its own permissions and its own audit trail arrives inside products you already pay for. Next time you rebuild a connection, rebuild it on that footing rather than on somebody's inbox.

Where fixing automation ownership is not worth your time

This work produces nothing you can show anyone. No extra bookings, no faster response time, no number that moves. What you buy is the absence of a bad week, which is a hard thing to feel good about spending money on.

Be honest about scale, then. Three automations and four staff doesn't need a project, and it doesn't need us. It needs the half-hour audit above, a text file and a calendar reminder every six months. If you ask us to quote for a workflow automation audit at that size, we'll tell you to do it yourself.

The fix carries real cost too. Some per-seat tools charge you for the extra licence a shared operations account needs, and plenty of smaller vendors offer no service account or company-level key at all. There you're stuck with a person's login, and the only honest mitigation is writing down which login it is and checking it the week they leave. Ownership questions like this run through everything we build, down to who owns the code when it's custom software.

The one automation check to do this week

Open the connections page of whichever platform runs your automations and read the account name beside each one. Not the automation names. The account names. If any of them belong to someone who has left, or to someone who might, you've found your Tuesday in May.

If you'd rather someone else did the reading, get in touch and tell us which platforms you use. We'll go through the connections, tell you which are a person and which are a system, and hand you the list in the order worth working through.