The demo always works. The problem shows up on a Tuesday at 3 a.m., when the CRM's API returns a 500, the flow stops halfway through an order and nobody notices until the customer asks. The difference between a toy flow and a production one is not in the nodes: it is in what happens when something fails.
Design assuming everything fails
- Retries with growing backoff: most API errors are transient; retrying after 30 seconds fixes what failed the first time.
- Explicit error routes: every critical step defines what happens if it goes wrong, even if it is just “alert and stop”.
- Idempotency: if the flow runs twice with the same order, it must not create two orders. Check before writing, always.
- Atomic steps: three small chained flows beat one forty-node flow that cannot be resumed halfway.
If it fails, it should tell you before your customer does
Every production flow sends its errors to a channel someone watches — Slack, email — with the context needed to act: what failed, with which data, and a link to the run. Execution history is kept so any incident can be reconstructed. “It broke three days ago and we didn't notice” is the most expensive design flaw there is.
Human checkpoints are not optional
Refunds, address changes, replies to angry customers: whatever has a high cost of error goes through a person — not because the machine can't, but because the day it gets one wrong will cost more than everything saved. Defining what the machine decides and what a person decides is part of the design, not a patch afterwards.
Measure reliability, not the feeling of it
Two numbers tell you whether an automation can be trusted: the share of successful runs (above 99% in a healthy production flow) and the time between a failure and someone knowing (minutes, not days). If your platform will not let you measure both, that is the first problem to fix.