How to document and hand over automations so they survive staff changes

Here’s a scenario we see often. A freelancer or a technical employee builds a handful of automations: leads into the CRM, orders into accounting, reminders to customers. Everything works. A year later that person moves on, an app changes its connection, something stops, and nobody knows what was built, where, or with whose login.

The fix isn’t more technology. It’s one page per automation, written while the builder is still around.

What goes on the one-page runbook

The template has these fields ready to copy for each automation.

Rules that make documentation useful

1. Write it during the build, not after. Documentation written “later” is never written.
2. Name things clearly in the tool too. “Website lead → CRM → team alert” beats “Workflow 7”. Name each step for what it does.
3. Never paste secrets into the runbook. Point to where they are stored.
4. Use company accounts for every connection. Personal logins break when people leave. See who owns your accounts?
5. Keep an inventory. One list of every automation, its owner and its runbook link, so nothing is forgotten.
6. Review quarterly. Click through each runbook. Is it still accurate? Does the alert still reach someone?

Handover checklist

When the person who built or maintains automations is leaving, or when an agency hands over to you:

• Inventory complete: every automation listed, including “small” ones
• Runbook for each, reviewed by the new owner
• All connections use company accounts. Personal ones replaced.
• Credentials in the company password manager, with access for the new owner
• Platform access: the new owner has an admin or owner account, and the leaver’s access is removed after handover
• Alerts go to a shared channel, not to the leaver’s inbox
• The new owner has fixed one simulated failure using only the runbook

The last item is the real test. If someone else can recover a failure from the runbook alone, the handover worked.

Where to keep runbooks

Somewhere the whole team can find them and that belongs to the company: a shared drive folder, the company wiki or a page in your project tool. Link each runbook from the automation itself (most platforms have a description or notes field) and vice versa.

One platform note: in n8n’s free self-hosted Community Edition, workflows and credentials are only accessible to the instance owner and the user who created them. If several people need access, plan for that when choosing how you host n8n. See self-hosting n8n: the real cost.

Frequently asked questions

Isn’t the workflow itself the documentation?

Partly. A well-named workflow shows how it works. It doesn’t show why it exists, who owns it, which accounts it relies on, or what to do at 9pm when the alert fires.

How long does a runbook take to write?

For a typical small-business automation, 20–30 minutes when written by the person who built it. Much longer when someone has to reverse-engineer it later.

We use an agency. Should they write these?

Yes. Make runbooks and an automation inventory part of the deliverable, along with confirmation that all accounts are in your company’s name. If you’d like your current automations documented and tidied up, that’s part of our tech stack service.