Contents
A CRM order exists, yet n8n reports an error. The connection failed after the record was saved and before confirmation arrived. Restarting the whole workflow could create a second order. Reliable n8n error handling starts with an operational question: what do we actually know about the outcome in the receiving system?
Give each business operation a stable identity
Associate each request with a stable reference from its source. Keep the event identifier, business operation identifier and n8n execution identifier in separate fields. Several executions can process one operation. Two legitimate orders can also contain identical products, so a content fingerprint alone may not distinguish them correctly.
Define the business states people need: received, write requested, confirmed, uncertain and intervention required. CRM and ERP automation should let operations staff find uncertain records without reading every technical log. Assign a person who can authorize recovery and specify how long the business can wait for that decision.
A successful write with a missing response
Consider a fictional distributor. Event COM-248 requests an order. The CRM saves order C-906, but the network response disappears. The workflow never receives C-906 and marks the outcome uncertain. It queries the CRM using reference COM-248 before trying to create anything again. This is a proposed design example, with no claim that a test was performed.
If one order matches the reference and expected contents, recovery records its identifier and continues. If no order appears, account for the API's visibility delay before deciding that the write failed. If several matches appear, pause the case for human review. A search that returns no result immediately after a timeout is incomplete evidence.
Where an API supports idempotency keys, follow the documented contract, including scope, retention and behaviour when a key accompanies different contents. Otherwise, investigate a unique reference enforced by the receiving system or a conditional write. A lock inside your workflow cannot stop another integration from creating the same object. Both systems determine the actual guarantee.
Separate the alert from the recovery decision
The n8n error handling documentation describes an error workflow that starts with Error Trigger and is selected in the main workflow's settings. That route can notify the support team. Give recipients a case reference and a specific next action while limiting the information included in the message.
A useful alert names the affected system, last confirmed step and whether the result is certain or uncertain. Keep full invoices, access tokens and personal customer details out of ordinary notifications. An investigation record may contain additional information under appropriate access controls and a defined retention period.
A technical success status does not close the business incident. The workflow might finish after delivering an alert while the order remains missing. Maintain a register of unresolved operations and assign each one an owner. A custom CRM and ERP can expose this reconciliation queue when existing software does not provide one.
Plan six failures along one business journey
Use the following scenarios as an acceptance protocol in an isolated environment. Prepare synthetic data, test accounts, a controlled receiving service and a way to simulate responses. No failure injection was performed for this article. Before approving live operations, collect separate evidence for every expected outcome, including what appears in the destination system.
TableSix situations to verify · shareable block
| Failure to introduce | Business outcome to inspect | |
|---|---|---|
| Timeout | Lose the response after order creation. | Reconcile with the existing object before creating another. |
| Replayed event | Deliver the same reference twice. | Recognize one operation and retain both reception records. |
| Stopped worker | Interrupt execution between actions. | Resume from confirmed results and expose uncertain cases. |
| API limit | Return a temporary rate limit. | Wait within the provider's rules and a bounded recovery window. |
| Invalid response | Return an incomplete or unexpected structure. | Reject validation and prevent silent progression. |
| Partial success | Create the order, then fail the notification. | Keep the order and retry the notification separately. |
Bound retries and preserve completed work
Set a maximum attempt count and a total processing window. An authorization failure needs an access correction; invalid input needs a data correction. Repeating either indefinitely adds load and delays valid cases. For a temporary rate limit, follow the provider's instructions and avoid making every pending record retry at the same instant.
The Wait node can pause a workflow. Choose timing and branches for the n8n version you run and the API contract you depend on. A waiting workflow does not reserve a resource at the provider. On resumption, check business conditions that may have changed, including cancellation of the original request.
Handle side effects separately. If order creation succeeds and an email fails, retain the order and recover only the notification step. A compensating cancellation needs its own business rule, particularly if another department has begun work. A custom web application can give authorized staff a practical interface for these decisions and their evidence.
Close the incident with evidence
For each scenario, record the workflow version, simulated inputs, final CRM state and actions actually performed. Count objects in the receiving system and compare them with expected operations. Capture investigation time and manual intervention as well. A successful exercise provides evidence for its scenario; it cannot establish an unconditional availability promise.
An operations owner accepts the business result while the technical team explains discrepancies. Retain troublesome cases for the next workflow change. The useful deliverable includes a reconciliation register and a test journal completed after execution.
Related implementation guides
Practical questions
Can every error be retried automatically?+
First classify the failure and the destination's state. An uncertain result and a permanent rejection require different handling and recovery decisions.
Does Error Trigger prevent duplicates?+
It provides a route for handling failed executions. Uniqueness depends on business references, controls and the receiving API's documented behaviour.
What if there is no idempotency key?+
Investigate an enforceable unique reference and conditional writes. Document remaining limitations and the cases that require human reconciliation.
Who authorizes a manual retry?+
Assign an operations owner who can inspect the real object and completed effects. Record the decision against the incident reference.
Review your workflow with Daillac
Bring one representative case, its exceptions and your acceptance criteria to scope the next step.
D
