Documenting the clicks is pointless: the tool already stores them
When someone looks up how to document automations, they almost always end up doing the same thing: screenshots of the editor, a step-by-step of which module follows which, and a description of every node. A full afternoon of work. And it's wasted work, because you're copying by hand the one thing the tool already knows on its own.
Make, n8n, Zapier or Power Automate show you the graph of the flow in two clicks: what triggers it, what comes next, which field maps to which. That's live and always current. Your screenshot isn't: it expires the first time the vendor moves a menu or changes the colour of a button, and from then on it documents an interface that no longer exists.
The side effect is worse than being out of date. Documentation that looks old stops being read, and the moment it stops being read everyone assumes the rest is lying too. A manual nobody opens is exactly as useful as having no manual, except you also have to maintain it.
The graph tells you what the flow does. It never tells you why. And the why isn't anywhere except in the head of whoever built it.
The bus factor: if only one head knows why, that's your real risk
The bus factor of a system is how many people can leave before that system is left with nobody able to understand it. In business automation the number is almost always one. One person built the flow, that person knows why the threshold is 48 hours and not 72, and that person is the one you call when something odd happens.
You don't need a bus. A holiday, a team change, a long absence or a better offer will do. And the uncomfortable part is that the flow doesn't break — that would be easy to spot: it keeps running punctually every day. What breaks is your ability to change it.
You can see it coming long before the disaster arrives. The symptoms of a bus factor of one are always the same five:
- Nobody touches the flow. Changes get bolted on the outside, in a new flow, because modifying the original is frightening.
- Every business change opens an archaeological debate. «Why is this like this?». Nobody knows, so it stays as it is.
- A duplicate shows up. Someone builds another flow that does almost the same thing, because starting from scratch was cheaper than understanding the existing one.
- A decision can't be explained. A customer or an auditor asks why the system did what it did, and the honest answer is that nobody knows.
- The flow freezes. When the person leaves, it stays switched on and nobody dares change it or switch it off.
Notice that not one of those five symptoms is cured by a screenshot of the editor.
The only thing worth writing down: the business rule
A business rule is the human decision the flow makes on your behalf while nobody is watching. It isn't «if status equals pending, send email». It's: «a customer who hasn't replied in 48 hours gets one follow-up, because the standard contract promises an answer within two working days and we don't want to break it; unless it's a large account, in which case the account manager gets alerted instead of the system».
Everything else — the module, the order, the field mapping — is implementation. It changes the day you change tools and nothing happens. The rule outlives the tool: if you migrate from Zapier to n8n tomorrow, the rule is the only thing you have to carry with you, and it's precisely the only thing that isn't written down anywhere.
Why that condition and not another
Every number in a flow came from somewhere: a service commitment, a sales promise, a legal requirement or — most often — a meeting two years ago. Write down which one. «48 hours because that's the deadline the standard contract promises» is a condition you can revisit the day the contract changes. A bare «48 hours» is an untouchable number nobody will ever dare move.
What exception it covers
The odd branches of a flow are almost never a whim: they're scars. That filter discarding orders below a certain amount is there because one day a batch of test orders came through and polluted the billing. Writing the scar down prevents the two things that happen when it isn't written: someone removes the filter for «cleanliness» and the incident comes back, or nobody dares touch it even though the original reason disappeared years ago.
Who it alerts, and what happens if nobody replies
What blows up in production usually isn't the logic: it's the open ending. A flow that escalates to a person has to say who, through which channel, within what deadline — and what it does if that person doesn't respond. If the answer is «it waits indefinitely», that's a decision too and it needs writing down, because the day an order sits stuck for a week somebody will ask whether that's a bug or the design.
Attached to the rule go three facts that aren't business logic but get lost just as easily: the owner — a person with a first and last name, not a department —, the credentials it uses — which account, whose, with what permissions — and the systems it touches, separating what it reads from what it writes. What it writes is what can scramble your CRM on a Tuesday afternoon.
This is where this guide brushes against governance and control of AI automation without being the same thing. Governance sets permissions, audit trails and the handbrake: that's control. This is knowledge. You can have perfect control over a flow nobody understands — and then the only thing you can do precisely is switch it off.
The minimum sheet: one page per flow, eight fields
If the sheet doesn't fit on one page, it won't be maintained. That's the entire design criterion. Eight fields, two-line answers, done:
- What it produces. The concrete output, not the category. «Adds one row per order to the logistics sheet», not «handles orders».
- Owner. A person. If the name on it no longer works here, the sheet has expired and you can see that at a glance.
- Business rule. The why behind each condition, with its origin. It's the long field and the only one that justifies the sheet existing.
- Exceptions. What edge case each branch covers and which incident put it there.
- Who it alerts. Person or queue, channel, deadline, and what happens if nobody replies.
- Credentials. Which account it uses, whose it is and with what permissions. No secrets inside the sheet, obviously: just the account name.
- Systems it touches. What it reads and what it writes, in two separate lists.
- What it does NOT do. The explicit boundary of the flow.
The eighth field is the one nobody writes and the one that saves the most arguments. «Doesn't touch invoices already issued», «doesn't write to the ERP», «doesn't reply outside business hours». Without that field, every incident starts with twenty minutes of ruling out whether it was this flow — and once a year has passed, everyone credits it with powers it never had.
Where the sheet has to live so it doesn't go stale
Here's the uncomfortable part, said plainly: if the sheet lives in a Confluence, a Notion or a separate Drive folder, it will go stale. It isn't the tool's fault, it's the distance. Whoever changes the flow is inside the editor, in a hurry, fixing something; if updating the sheet means opening another tab, finding the page and editing, they won't. Once is fine. By the tenth change, the sheet is lying.
The sheet has to live where the flow lives. Three places that genuinely work, from least to most effort: the description field or notes on the scenario itself — Make, n8n, Power Automate and nearly all of them have one — where friction is lowest because you're already inside; a README next to the exported JSON if you version your flows in a repository, which throws in change history for free; and a pinned note in the channel the flow posts to, when its output is a notification.
The wiki doesn't disappear: it changes role. It stops being where the documentation lives and becomes the index — which flows exist, who owns each one and where its sheet is. That does hold up, because it's a short list that barely changes. What doesn't hold up is the detail sitting far from the place where it gets touched.
Updating the sheet is part of changing the flow, not a separate task
All documentation dies the same way: someone writes it in a one-off push and, from then on, maintaining it is «a task» competing with real work. It competes and it loses, every time, because it's never urgent and nobody is waiting for it.
The only way to stop that is to take it off the task list and put it inside the definition of done. Changing a flow isn't done when the flow works: it's done when the flow works and its sheet says what it does now. That's two minutes if the sheet is one click away, and they're two minutes that only ever happen if nobody treats them as optional. Everything else — quarterly reminders, documentation drives, internal audits — is theatre with a calendar.
That's what closes the loop with the rest of the cluster. A flow with a sheet and an owner is a flow you can keep alive without guessing, and a flow that doesn't end up as one of those zombie automations nobody switches off because nobody knows what breaks. Documenting neither maintains nor retires: it turns maintaining and retiring into decisions instead of bets. If you're building all of this from scratch, the full map is in the guide to automating with AI.