unit U5 — 5 of 5
Handover
runbook, alerts, credential owners
The automation is finished when someone other than you can run it. That means the client, or the next person at your agency, can tell whether it is healthy, knows what to do when it is not, and is not dependent on you remembering how it works. Handover is the difference between a project you delivered and a project you are permanently on the hook for.
Three artefacts carry it. A short runbook: what this flow does, what it touches, what to check first when it misbehaves, and how to roll it back. A monitoring signal the client can actually see — an alert on failure rate or on a queue backing up, delivered somewhere they already look, not a dashboard nobody opens. And a named owner on each credential, with an expiry, so the integration does not quietly die the day someone leaves and their API key is deactivated.
Where it breaks: the flow only you understand. It runs perfectly for months, then fails while you are unreachable, and the client has no idea whether it is their CRM, your automation or the weather. Write the runbook while you still remember the awkward parts, and make the first line of it the thing you would check first.
worked example
A handover runbook short enough that someone will actually read it during an incident.
FLOW: acme-lead-intake
DOES: portal webhook -> validate -> enrich -> Acme CRM upsert
TOUCHES: Acme CRM (write), Clearbit (read), Postmark (send)
FIRST CHECK WHEN IT MISBEHAVES
1 run history: are runs failing, or not arriving at all?
not arriving -> the portal stopped sending; check their webhook config
failing -> read the failed step's error message
2 dead-letter store: how many items, and what is the common error?
3 connections: has a credential expired? (see owners below)
ROLLBACK: re-publish the previous version from version history
ALERTS: #acme-automation (fires on failure rate > 5% for 10 min)
OWNERS: acme_crm -> [email protected], expires 2026-12-01
clearbit -> [email protected], expires 2027-03-01field checklist
- Write a runbook whose first line is what to check first.
- Send alerts where the client already looks, not to a dashboard.
- Alert on failure rate and backlog, not on every single error.
- Give every credential a named owner and an expiry date.
- Confirm someone else can follow the runbook without you.
common failure — The automation only one person understood
A lead pipeline ran flawlessly for five months, then began failing while its author was on leave. The client could not tell whether the fault was their CRM, the automation or the enrichment vendor, and there was no runbook, no alert and no record of who owned the credentials. Write the runbook at handover while the awkward parts are still fresh, route an alert somewhere the client already reads, and put a name and an expiry on every credential.
check your understanding
An alert that fires on every individual failure trains everyone to ignore the channel. What should the alert fire on instead?
sandbox validation
The check above confirms you followed the unit. Marking the module COMPLETED takes more: build the automation in your own engine and submit the exported flow and its run evidence, signed, to your unique validation URL. See the module page for that spec.