unit U4 — 4 of 4

Error handling & retries

failure branches, retries, dead-letter

The question in production isn’t whether a step will fail but what happens when it does. By default a thrown error aborts the whole run, so one malformed item can stop a batch of a thousand. The engine gives you two controls: per-step “continue on failure,” which routes a failed item down an error branch instead of killing the run, and automatic retries with backoff for transient failures (a rate-limit or a blip). Design both before go-live, not after a client reports missing data.

The durable pattern is a dead-letter branch. Set the risky step to continue on failure and wire its error output to a path that records the failed item — with the error and enough context to replay it — into a store or a “failures” sheet. Healthy items flow on; poison items are quarantined, not lost. Enable retries (e.g. 3 attempts, exponential backoff) on steps that call flaky externals so a transient error self-heals before it ever reaches the dead-letter branch.

Where it breaks: silent swallowing. Turning on continue-on-failure without capturing the error output means bad items just vanish — the run is green and the data is quietly incomplete. Always route the error output somewhere durable, and alert on a spike.

worked example

A continue-on-failure enrichment step routing failures to a dead-letter store while good items proceed.

[Webhook trigger]
      |
      v
[HTTP Enrich Piece]   (continue on failure: ON, retries: 3 x backoff)
      |-- success --> [Edit Fields: clean]        --> [CRM Upsert Piece]
      \-- error   --> [Code Piece: {item,error,ts}] --> [Dead-letter store]

field checklist

Enable continue-on-failure on steps that touch flaky externals.
Turn on retries with backoff so transient errors self-heal.
Route every error output to a durable dead-letter store.
Capture the error message and enough context to replay.
Alert on a failure spike, not on each individual error.

common failure — Continue-on-failure that swallowed errors

A step had continue-on-failure enabled but its error output went nowhere, so failed items silently disappeared; the flow ran green nightly while ~3% of leads never reached the CRM, undiscovered until the client counted. Route the error output to a dead-letter store with the message and payload, add retries for transient failures, and reconcile processed counts against input counts each run.

check your understanding

A step has continue-on-failure enabled. The nightly run is green, yet about 3% of leads never reach the CRM. What is missing?

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.