You Inherited an Automation Built by Someone Who Left. What Now?

What should you do with an automation built by someone who left the company?

Do not change it on day one. Map what it touches, find out what breaks if it stops, and write down what it actually does before deciding to keep, fix, or replace it. An inherited automation is still doing work for the business. The risk is not that it exists, but that nobody understands it.

Every growing team ends up here. A marketer who was handy with Zapier, an ops lead who built half the CRM logic in Make, a contractor who wired up n8n on a spare server. Then they move on. The workflows keep running, quietly, until one day a lead goes missing or a report shows numbers nobody can explain.

I use a fixed audit for these systems. It is slower than diving in and fixing the first error you see. It is also the only approach I trust when the person who knew the answers is gone.

Why is an inherited automation riskier than a new one?

An inherited automation is riskier because its assumptions are invisible. The builder knew which fields mattered, which edge cases they ignored, and which downstream tools depended on the output. None of that lives in the workflow itself. When you change one step, you can break something three systems away without any error appearing.

New automations fail loudly because you are watching them. Old ones fail quietly because nobody is. A workflow that has run for two years has had two years for other systems to start depending on it. A sales report might rely on a field it sets. A Slack channel might expect its alert. Someone may have built a second automation that triggers off the first.

That web of dependencies is the real asset and the real danger. I explained the business side of this in the cost of an automation nobody owns. The technical side is what this audit addresses.

What is the first thing to check in an inherited workflow?

Check who owns the account it runs under. If the automation lives in a personal account belonging to someone who left, it can stop the moment that account is closed or that person's card expires. Moving it to a company-owned account with shared access is the first fix, before any logic change.

This sounds administrative, and it is. It is also the single most common way inherited automations die. Connections in tools like Zapier, Make, and n8n are usually authorized by a person. If that person's HubSpot user is deactivated, or their Google account is suspended, every connection they authorized can fail at once.

List every connected app and note which user authorized it. Re-authorize each connection with a shared service user where your tools allow it. Do this one connection at a time, testing after each, so you know exactly which change caused any problem.

How do you map what an automation actually does?

Map it from the outside in. Write down every trigger, every system it reads from, every system it writes to, and every field it changes. Then check recent run history to see which paths actually fire. Many inherited workflows contain branches that have not run in months, and those branches are where the oldest assumptions hide.

I write the map in plain sentences, not diagrams. "When a form is submitted on the website, this workflow looks up the company in HubSpot, creates it if missing, sets the lifecycle stage to lead, and posts a message to the sales channel." A sentence like that is easy for anyone to check against reality.

Run history is your best evidence. Most automation platforms keep a log of past runs, though how far back it goes depends on the platform and plan, so check your vendor's docs. I covered how to read that history in using Zapier run history to debug a broken Zap, and the same logic applies in Make or n8n.

How do you find out what depends on the automation?

Search for its outputs. Every field it writes, every channel it posts to, and every file it creates is a possible dependency. Check reports, dashboards, other workflows, and team habits that use those outputs. Then ask the people closest to them what they would notice if the automation stopped tomorrow.

In a CRM, look for reports and lists that filter on fields the automation sets. In Airtable, look for views and synced tables that read from its output. In Slack, look for channels where its messages land and check whether anyone reacts to them. Silence in a channel is a strong hint that nobody depends on that part.

The human question is the one people skip. Ask the sales lead, the marketing manager, and whoever runs reporting. People often depend on an automation without knowing it exists. They just know the leads show up, or the numbers are ready on Monday.

Should you keep, fix, or replace an inherited automation?

Keep it if it works, is understood after your audit, and runs under a company account. Fix it if the logic is sound but brittle. Replace it if nobody can explain why it exists, if its logic contradicts current processes, or if fixing it costs more than rebuilding with clear documentation from the start.

My bias is toward keeping more than people expect. A working automation that you now understand has a track record. A rebuild has none. Rebuilding feels cleaner, but it resets the clock on every edge case the original builder already handled, often without writing it down.

Replacement makes sense when the automation encodes a process the business no longer follows. If lead routing changed a year ago but the old workflow still assigns owners by the old rules, patching it just layers new logic on old. In that case, start fresh and retire the old version on a planned date.

How should you change an inherited automation safely?

Change one thing at a time and keep the old version available. Duplicate the workflow before editing, make a single change, run it against test data, and compare the output with the original. Only switch traffic once the results match. If something breaks, you can turn the copy off and the original back on.

Test data matters more than people think. Running an edited workflow against live records is how teams end up with duplicate contacts, wrong owners, or emails sent twice. A small test segment, a sandbox portal, or a copy of the Airtable base gives you room to be wrong without customers noticing.

Pair each change with a short written note: what you changed, why, and how to undo it. That note is the documentation the original builder never left. In six months, you will be glad you wrote it, and so will whoever inherits the system from you.

What documentation should you leave behind?

Leave a one-page record per automation: what triggers it, what it reads and writes, who owns it, which account it runs under, what depends on it, and how to turn it off safely. Store it where the team already looks, not in a personal folder. The goal is that the next person never has to run this audit.

I keep this record next to the automation itself when the tool allows notes, and in a shared doc or Airtable base when it does not. The format matters less than the habit. A short, current record beats a long, outdated one every time.

The test for good documentation is simple. Could someone who has never seen this workflow turn it off safely at two in the morning using only your notes? If yes, you are done.

What should you do next?

List every automation you inherited, check which account each one runs under, and move anything on a departed person's account to a shared company account first. Then map one workflow per week in plain sentences, find what depends on it, and write the one-page record before making any logic changes.

The audit is slow on purpose. Speed is what got the business into a situation where critical workflows depend on someone who is no longer around. Understanding first, changes second, is the only order I trust.

If you have inherited a tangle of Zapier, Make, or n8n workflows and want someone to audit and document them properly, reach out. Let's chat about what you are running.