Plan partial-failure recovery by listing every completed side effect, its evidence and the person authorised to repair or accept it. Do not assume that a workflow failure reverses actions already performed elsewhere.
Define recovery as a business outcome
Recovery may mean continuing unfinished work, correcting a record, releasing a reservation or asking a person to resolve a discrepancy. It does not always mean returning everything to its original state.
n8n documentation describes connected-node workflows and includes executions as a core topic. This supports reviewing a sequence and its execution evidence. The supplied material does not promise cross-system rollback or a compensation feature.
Define an acceptable final state before building. “No error displayed” is weaker than “one valid request exists, its reservation is accounted for, and the responsible team knows its status.”
Create a compensation ledger
For each side effect, write these fields:
- Completed action: what changed outside the calculation itself?
- Proof: which reference establishes completion?
- Dependency: which later actions rely on it?
- Repair choice: continue, correct, release, cancel or leave in place with explanation.
- Owner: who may approve and perform that choice?
- Recovery evidence: how will the final state be verified?
Also record whether repair itself creates another side effect. A corrective message, for example, does not erase the first message; it creates additional communication that must be intentional.
Walk through a halfway failure
In a hypothetical Ahmedabad distributor, synthetic request R-208 requires an internal request record, a reservation of five units and a warehouse instruction.
Assume the record exists and the five-unit reservation is confirmed, but the instruction fails before its outcome can be established.
The ledger should require the warehouse owner to check whether an instruction exists. If it does, reconcile its reference. If it does not, choose whether to complete the instruction or release the reservation under the agreed policy. If the check is inconclusive, keep the case visibly unresolved.
Evaluate recovery using concrete questions: Is there exactly one valid request? Are five units still reserved intentionally? Is there one accountable owner? Has anyone avoided creating a duplicate instruction? These are synthetic conditions, not a platform test.
Establish a recovery handoff
Stop unattended processing when no owner can determine which effects completed. Next, hand over the ledger, execution reference and synthetic reproduction details, excluding private material from shared examples.
If purchasing access for implementation, check the automation catalog for access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or rollback protection.
Sources and scope
Source material checked 29 October 2026; features/policies may change. n8n workflow documentation establishes the workflow model and execution context. The compensation ledger and recovery choices are editorial advice, not claims of built-in rollback.