Your automation broke and nobody remembers how it worked

# Your automation broke and nobody remembers how it worked

Most people think automation fails because of bad tools.

It usually fails because nobody remembers how it works six weeks later. The person who built it is on something else, the person fixing it is reading a canvas of unlabelled boxes, and the only sentence anyone can produce is "the automation is broken."

That sentence is the problem. It is not a fault report. It is a shrug.

## What breaks is the sequence, not the tool

Process maps at the high level are easy and mostly safe. The danger sits one level down, in the sequences: tags change, contacts move between pipelines, notifications fire. This is where things break quietly, because nothing errors out. The flow just stops doing what you assumed it did.

If you cannot say where an automation starts, why it fires, and what it outputs, every revision is guesswork. You are not editing a system, you are poking it.

So every automation needs four things written down before it is built:

- A clear start trigger - A defined processing flow - A predictable output - One central source of truth

Not memory. A map.

## Tools are not interchangeable, and mapping is how you find out

Zapier, Make, GoHighLevel. Each has strengths and blind spots. Some triggers exist in one and not the other. Some logic works natively; some needs duct tape and a webhook.

Map the steps first and you choose the tool. Build first and the tool chooses for you, and you find out at step seven when the thing you need does not exist.

Mapping forces the questions early:

- What triggers this? - Where does data get stored or modified? - Which tool actually supports this step? - What happens when something fails?

That last one is the one people skip.

## One example: the form that is actually six automations

"We automated the intake form" sounds like one thing. Written out, it is six:

1. Client fills out the form 2. Tag gets added 3. Owner receives an SMS 4. Owner receives an email 5. Client gets the booking link 6. Process ends cleanly

Number them. Not for tidiness. So that when it breaks in March, nobody says "the automation is broken." They say **2.3 failed**, and the person fixing it knows which step, which tool and which record before opening anything.

## The honest limit

Numbering does not stop things breaking. Platforms change triggers, APIs deprecate, a field gets renamed by someone in a hurry. A map will not prevent any of that.

What it changes is the time between "something is wrong" and "here is the step." That is the whole return, and it is enough.

## The takeaway

- Automation without documentation is fragile - Numbered steps create accountability - Clear sequences reduce downtime - Maps make it possible for someone else to work on your system

Automation is not really about building systems. It is about being able to fix them when they break, because they will. That only happens if you mapped it first.

---

*Daniel Galang builds automation systems in Zapier, Make and Airtable.*