Inheriting somebody else's automations

This situation is more common than you would think. An agency relationship ends, a contractor moves on, an internal person who built things in their spare time leaves. What remains is a set of automations that are load bearing, undocumented, and unowned.

The instinct is either to leave it alone or to rebuild everything. Both are wrong. Here is the sequence that works.

Step one: inventory before anything else

You cannot manage what you cannot list. The inventory is harder than it sounds because automations hide in places nobody thinks to look.

• The obvious platforms: n8n, Zapier, Make, Power Automate, the CRM's own automation section
• Spreadsheet scripts: Apps Script attached to Google Sheets is the single most common hiding place
• Scheduled jobs on servers, including the one nobody has logged into for a year
• Email rules and filters doing routing work
• Webhooks registered with third parties, pointing at endpoints somebody built
• Database triggers and stored procedures

For each one: what it does, what triggers it, what it writes to, when it last ran, and whether it succeeded.

Step two: rate by impact and fragility

Two axes. Impact is what breaks in the business if this stops. Fragility is how likely it is to stop, judged on error rate, dependency count, credential ownership, and how recently the connected APIs have changed.

Step three: take ownership of credentials

This is urgent and gets postponed. Automations built by a departed person frequently authenticate as that person. When their account is deactivated, everything they built stops at once, usually on the same day, usually without warning.

Move every connection to a service account owned by the business. Do this before the leaver's account is closed, not after.

The most common cause of a sudden multi system automation outage is somebody's account being deactivated on their last day.

Step four: add monitoring before you change anything

You want to know the current failure rate before you start editing, for two reasons. It tells you which workflows are actually unhealthy rather than merely undocumented, and it gives you a baseline so you can tell whether your changes helped.

Step five: document as you touch

Do not attempt to document everything up front. It is a large job with no immediate payoff and it will stall. Document each workflow at the moment you first need to work on it, while you have the context loaded. Within a few months the important ones are covered and the unimportant ones have documented themselves as unimportant by never coming up.

What not to do

Do not rebuild on principle. Plenty of inherited automations are fine. They are undocumented and unowned, which is a different problem from being badly built, and the fix for that is documentation and ownership rather than a rewrite.

What this usually costs

For a typical small business estate of fifteen to forty automations, inventory and risk rating is a few days, credential migration is a day or two, and the critical fixes are usually a week or so. It is considerably cheaper than the outage it prevents.