What happens when the person who built your workflows isn't there
A workflow has been running for months without anyone touching it. Then one day it stops, and the only person who understands it is unreachable. The bus factor problem in no-code automation, and the five habits that close the gap before it costs you.
What happens when the person who built your workflows isn't there
A few months ago, a CTO called me from a hotel lobby in Lisbon. He was supposed to be on a four-day break. Instead, he was on his phone, walking his head of operations through the structure of a Zapier workflow that had stopped firing.
"I built it," he told me later. "Two years ago. It hasn't broken since. I forgot it existed."
The workflow processed roughly 300 customer order confirmations a day. When it stopped, the orders piled up unnoticed for half a day. By the time someone realized, the team had no idea where to look. The CTO was the only person who knew the account, the logic, and the way the modules were named.
Some teams call this the bus factor problem, and it lives in nearly every automation setup I see. If the person who built a critical workflow gets hit by a bus, or just goes on vacation, does the business keep running, or does it grind to a halt?
In most companies I audit, the answer is the second one. They just don't know it yet.
Why no-code makes it worse
In traditional software development, knowledge has structure. Pull requests, code reviews, version histories, shared repositories. Even when a developer leaves, the code is sitting in a repo, readable and traceable. Someone else can step in, struggle for a couple of weeks, and eventually understand what's there.
No-code platforms like Make, Zapier, or n8n don't have those structures by default. A workflow is a visual diagram saved inside one person's account. There are no pull requests. There are usually no formal reviews. Versioning, where it exists at all, tends to be nominal.
Three concrete consequences:
The knowledge sits in one head. The workflow runs, so nobody opens it. Once it stops running, only the original builder can reconstruct what it does. Nobody else has spent time inside the diagram.
Access is private. The workflow runs from a personal Make or Zapier account, because that was the fastest way to ship. Nobody else has credentials. Nobody else can read the run logs. Nobody else can intervene when something breaks.
Documentation doesn't exist. People who build no-code workflows rarely feel like they are building "real software." Documenting it feels like overkill for the task. So they skip it. Until it isn't overkill anymore.
When the bill arrives
The bus factor problem is invisible while everything works. It surfaces in four predictable scenarios:
Illness or resignation. The original builder is suddenly unavailable. What's left is a diagram nobody understands.
External changes. An API updates. A vendor introduces new auth requirements. The workflow stops. The only person who could repair it built it eighteen months ago and barely remembers it.
Business shifts. Sales restructures. Lead routing has to change. Someone else tries to modify the workflow, doesn't grasp the logic, and breaks something they didn't realize they could break.
Audits or compliance reviews. Somebody asks: what data flows through this workflow, and where does it land? Nobody can answer. The person who would know is not reachable or no longer remembers exactly.
In every one of these cases, the cost of recovery is multiples of what it would have cost to build the workflow correctly the first time. Sometimes five times. Sometimes ten.
What actually helps
There is no tool that solves this. It's a discipline problem, and the discipline has to be in place before the first workflow ships, not after.
Shared accounts, not personal ones. Every workflow that the business depends on lives in a team account. Make, Zapier, and n8n all offer team plans. They cost more. They are worth it.
A short description on every workflow. Three sentences. What does this workflow do? When does it fire? Who owns it? Either as a comment in the first module or as a notes field on the workflow header. Anything that makes the diagram readable to a stranger.
A two-person rule. Every production workflow has a primary owner and a secondary. The secondary has been walked through the workflow at least once, has access, and could plausibly modify it under pressure.
A semi-annual handoff. Twice a year, owners and secondaries sit together, walk through every production workflow, verify that descriptions are still accurate, that credentials still work, that the logic still matches the business. Two hours, twice a year. Cheap insurance.
Clear thresholds for what counts as production. Not every workflow needs this treatment. A one-off data import, an experiment between two team members, a personal helper, those don't need any of it. But once a workflow becomes business-critical, the rules apply. Define the threshold explicitly, or everything stays informal until something breaks.
A quick test you can run today
Take a piece of paper. List every automation running in your business right now. Make, Zapier, n8n, Power Automate, custom scripts, anything that fires without a human pressing a button.
For each one, three questions:
1. If this workflow fails tonight, who can repair it tomorrow? 2. If that person is unreachable, who else could repair it? 3. Where is the logic documented?
If, for more than a third of your workflows, you can't answer all three clearly, you have a bus factor problem. It stays quiet until something fails or somebody is missing. By then, fixing it is far more expensive than preventing it would have been.
The real point
Automations are not "just tools." They are business logic that happens to live inside a tool. When that logic exists only in one person's head, it is a single point of failure that doesn't show up in any system diagram, but can land at any moment.
Most companies learned this lesson about software architecture decades ago. They are two or three years behind on automation. The pain points are obvious enough that this gap will close. Until then, you can save yourself a few unhappy phone calls by closing it earlier.
If you want to know where the single points of failure are hiding in your own automations, the free Automations Check gives you a clear picture in about 30 minutes.