Distinguish Failed and Partially Completed Workflows
Build a step-level ledger that separates confirmed effects, non-execution and uncertainty before choosing a safe recovery action.
10/24/20263 min read
A workflow can fail after completing part of its job. Calling the whole run “failed” hides those completed effects; calling it “successful” hides the missing ones. Recovery begins with a step-level account of what happened, not a decision to rerun everything.
Use a state ledger that separates local processing from downstream effects. Each step needs an intended outcome, an observed result and an evidence reference. The workflow's overall status should be derived from those facts rather than substituted for them.
Map the intended result
The fictional workflow for Alder Quay Services prepares a reviewed research packet, stores it in an internal document area, creates an internal review task and links the task back to the account. All examples here are synthetic and describe a recovery design; no live systems are being changed.
The intended result is not merely four green nodes. It is one accessible packet, one review task pointing to that packet and one correct account link. A node can report success while the business object is wrong, so the ledger needs destination references and validation criteria.
Fill the partial-completion ledger
Step 1, prepare packet: completed locally; packet revision P6; validation passed; no external effect.
Step 2, store packet: confirmed complete; document reference D41; destination read confirms expected title and revision.
Step 3, create review task: uncertain; request submitted but response lost; operation reference O82 retained; destination outcome not established.
Step 4, link task to account: not attempted; depends on a verified task reference from Step 3.
Overall state: partial, with one uncertain effect. The permitted next action is to reconcile O82 in the task destination, not restart Step 2 or assume that Step 3 did nothing. The account link remains blocked until the task identity is known.
Add ledger fields for last checked time, responsible operator, approval reference and recovery decision. Keep request metadata minimal. Do not copy authentication headers or full customer content into a general incident queue.
Use a recovery decision tree
First ask whether a step was attempted. If not, it may be eligible for later execution after its prerequisites and authorization are verified. If attempted, ask whether completion is established. Confirmed success should not be repeated merely because a later step failed.
If non-execution is established, consider a bounded retry under the service's rules and the original authorization. If the outcome is uncertain, investigate using supported destination evidence. Absence from a delayed view is not automatically proof that nothing happened. If evidence cannot resolve the state, hold and escalate with the operation reference.
For the fictional case, suppose the destination shows task T19 carrying O82 and pointing to D41. Update Step 3 to confirmed complete, then separately verify whether Step 4 remains authorized and needed. If T19 points to the wrong document, the issue is not a simple missing step; it requires an approved repair decision.
Do not confuse error handling with compensation
n8n allows a separate workflow to handle execution failures. That mechanism can route an alert or review task, but its presence does not demonstrate reversal of earlier remote effects. Design compensation separately for changes that are actually reversible and authorized to repair.
A packet may be removable under policy, but deleting it while a task still references it can create another problem. Recovery order depends on the business relationships, not only the reverse order of nodes. Preserve legitimate work completed by people after the partial run.
Rehearse each interruption point
Use mocks or an approved sandbox to stop after every state-changing boundary. Include failure before submission, lost response after acceptance and failure after the final write but before local logging. Check that the ledger distinguishes these cases and that operators can identify the next permitted step.
Close the incident only when every intended effect is confirmed, deliberately abandoned or assigned an explicit unresolved disposition. A rerun that finishes without errors is not enough if it leaves duplicate documents or orphaned tasks behind. The desired recovery outcome is understood business state, not a cleaner execution history.
If you are also choosing research access, ask about Leads Automation’s independent Sales Navigator offer at US$15/month on WhatsApp. Confirm the available plan, eligibility and terms before ordering; Leads Automation is not affiliated with LinkedIn. This is not LinkedIn’s official price or an assurance that any particular integration is included.