← All articles

September 15, 2026

The Person Who Built Your Automations Left. Here's What Actually Breaks.

When the person who built your automations leaves, they keep running but the error alerts reach nobody. Fix ownership and alerts before you rebuild.

ST

Stuart

Founder, Hotkey

Your automations didn’t stop when the freelancer left. That’s the problem.

The Zap that pushes website leads into your CRM ran fine on their last day, and it’ll probably run fine next week. Then someone changes a password or renames a form field, and it fails. Zapier sends an error email. To the person who built it.

When the person who built your automations leaves, the automations usually keep running. What stops is anyone finding out when they break. Zapier sends error alerts to the account’s own email address by default, and on Free or Professional plans it can’t hand that account to you. So before you rebuild anything or hire anyone, take ownership, point every alert at a shared inbox, and list what each automation touches.

Why inherited automations break without anyone noticing.

An orphaned automation is a workflow that still runs in production but has no owner inside the company who gets told when it fails. Every major no-code platform sends failure news to a person, and after a handover that person is usually gone.

Zapier sends error notifications to the Zapier account’s email address by default. If the freelancer built on their own login, that’s their inbox. And if a Zap errors too many times, Zapier turns it off. Make deactivates a scenario after a set number of consecutive errors, and a scenario started by an instant trigger such as a webhook switches off on the first one. n8n only tells anyone if someone built an error workflow with the Error Trigger node and attached it in each workflow’s settings.

Platform	Who gets told about errors	What repeated errors do	How you take it over
Zapier Free or Professional	The account’s email address	The Zap gets turned off	Zapier won’t transfer it. You need control of the login email.
Zapier Team or Enterprise	The Zap owner’s email address	The Zap gets turned off	The owner or a super admin transfers the Zaps
Make	Each member, per their own email preferences	Scenario deactivates. Webhook scenarios on the first error.	Admin access to the organization it lives in
n8n	Nobody, unless an error workflow was set up	Each run fails and gets logged	Access to the instance and the server it runs on

So the failure is silent twice. The run fails, then the automation switches itself off. What’s left is the business consequence: form leads that never reach the CRM, onboarding emails that stop going out, invoices nobody created. You hear about it when a customer asks why nobody called back. It’s the same pattern that makes some tasks worth automating first: the expensive failures are the things that quietly don’t happen.

How do I get access to Zaps built on someone else’s account?

Getting control of the accounts comes first, and your Zapier plan decides how hard that is. On Zapier’s Team or Enterprise plans, the account owner or a super admin can transfer a departed member’s Zaps and update their connected app accounts. If you’re the owner, it’s an admin task.

On Free or Professional, Zapier says plainly that it can’t transfer the account, update its connected app accounts, or give anyone else access. The only route it documents is regaining control of the email address the account was registered to, for example by having your IT admin reset the password. If the freelancer signed up with a personal Gmail, you need their cooperation or you’re rebuilding.

Make and n8n follow the same logic. Whoever controls the Make organization or the n8n server controls the workflows. A self-hosted n8n instance running on the freelancer’s own cloud account is the hardest version of this problem, because you don’t just need a login. You need the server.

Then check the connections inside each automation. A Zap you now own can still be authenticated as the ex-builder’s CRM user or Gmail account, and it breaks the day that user gets deactivated. Reconnect every app with a company-owned account.

Move the alarms before you touch the logic.

Rerouting the alerts turns a silent failure into a loud one, and it’s the cheapest step in this whole list. Create a shared inbox such as automations@yourcompany.com, give it one named owner, and send everything there.

In Zapier, the error notification setting has four options: immediately, immediately then an hourly summary, an hourly summary, or never. Pick immediately for anything that touches leads or money. Zapier Manager can also email you when a Zap gets turned off, which catches the second, quieter failure.

In Make, turn on storing incomplete executions so failed runs are kept for retry instead of disappearing. In n8n, build one error workflow that emails the shared inbox and set it as the error workflow on every production workflow. n8n’s docs are clear that you can’t test it with a manual run. It only fires when an automatic run fails.

Do this before you change anything else. If you edit a workflow first and it breaks, you’ve recreated the exact problem you’re trying to fix.

Alerts have one real limit, and it’s worth being honest about. They only catch errors. An automation that runs successfully and writes the wrong thing won’t trigger anything. We run always-on agents in our own stack, and the worst failure we’ve had wasn’t a crash: a post-call agent quietly wrote duplicate notes into the CRM, and nothing alerted, because technically nothing had failed. For anything that writes to your CRM, someone still has to look at the output once a week.

One row per automation, and the column that matters.

Documenting inherited automations doesn’t need a wiki. Automation documentation for a small firm is one row per automation with four columns: what triggers it, what it writes to, who notices if it stops, and who owns it now.

“Who notices if it stops” is the column that matters. If the honest answer is “a customer, eventually”, that automation goes to the top of the list. Expect to find a few automations nobody in the company can explain.

Should you rebuild automations a freelancer left behind?

Not yet. Rebuilding before the inventory means rebuilding things you don’t need, on a timeline set by panic.

For each automation nobody can explain, run a switch-off test. Turn it off, write down the date and wait two weeks. If nobody notices, delete it. If someone does, you’ve just found its owner.

Rebuild only when one of three things is true: the automation depends on an account you can’t recover, it keeps breaking after the alerts are fixed, or nobody can say what it’s for even after the switch-off test. If you run one to three simple Zaps, do the first two steps and stop there. If your lead flow, onboarding or invoicing runs through automations, do all of it this week.

There’s one case where hiring help early is the right call: automations on a self-hosted n8n server with custom code nodes nobody in the company can read. A short handover audit is worth paying for there. Just not before you own the accounts.

The rule going forward costs nothing at the start and a lot to fix later. Automations live on accounts the company owns, alerts go to a shared inbox, and every automation has one named owner. When someone builds you an automation, the handover isn’t finished until all three are true.

Frequently asked questions

Can Zapier give me access to an ex-employee’s Zaps? On Zapier’s Team and Enterprise plans, the account owner or a super admin can transfer a departed member’s Zaps and update their connected app accounts. On Free and Professional plans, Zapier can’t transfer the account or grant anyone else access to it. The only route Zapier documents is regaining control of the email address the account was registered with.

Why did my Make scenario turn itself off? Make deactivates a scenario after a set number of consecutive errors, configured in the scenario settings. Scenarios started by an instant trigger, such as a webhook, switch off on the first error. Turning on stored incomplete executions keeps failed runs so they can be retried instead of lost.

How do I know if an automation has stopped working? You only find out if the error alerts reach someone who reads them. Point Zapier error notifications, Zapier Manager’s turned-off alerts and an n8n error workflow at a shared company inbox with one named owner. Alerts won’t catch an automation that runs and writes the wrong thing, so someone should also check its output once a week.

Should I rebuild automations a freelancer left behind? Not before you’ve taken ownership of the accounts, rerouted the alerts and listed what each automation does. Turn off any automation nobody can explain, and delete it if nobody notices within two weeks. Rebuild only what’s tied to an account you can’t recover, keeps breaking after the alerts are fixed, or still has no clear purpose.

Who should own automations in a small business with no ops person? Each automation should have one named owner, usually the person who depends on its output, such as the head of sales for lead routing. That owner doesn’t need to build anything. They need access to the account, the alerts in their inbox, and the authority to switch the automation off.

— Stuart, Hotkey