Workflow pattern · Integration reliability
Celigo error recovery
Separate retryable integration failures from data, process, and ownership problems.
Integration errors arrive as a flat log: every failed flow run looks equally urgent until someone classifies it. Without that step, teams either ignore alerts until something breaks visibly, or retry blindly, which can double-post a record that was already correct on the first attempt and just reported a false failure.
Classification is what makes retry decisions safe: transient failures (a timeout, a rate limit) are fine to auto-retry on a bounded schedule, while failures rooted in bad data or a mapping gap are not; retrying just repeats the same failure. The runbook tells the system owner which category applies before they touch anything.
The payoff shows up as the error log matures: instead of a flat list where every entry looks the same, recurring signatures point straight at their fix: a partner's field format changed, a mapping needs a new rule, a rate limit needs a longer backoff. The queue becomes a source of upstream integration fixes, not just a place errors go to be dismissed.
Target outcome
Cleaner retry decisions, fewer recurring errors, and a clearer path from alert to resolution.
Risk tier
Medium
Human gate
System owner approves destructive retries or record-level corrections.
Systems involved
Where this pattern lives
01
Celigo
02
NetSuite
03
Commerce channels
04
Notifications
Controls to define
The governance you set first
01
Error classification
02
Retry rules
03
Runbook links
The runbook
How this pattern runs, step by step
- 01Capture: the failed flow run and its error payload land in the queue alongside the record it was processing.
- 02Classify: the error is coded as transient (timeout, rate limit), data (missing or malformed field), or process (mapping or ownership gap).
- 03Auto-retry transient errors: on a bounded schedule with a cap, so a real outage does not loop indefinitely.
- 04Hold data and process errors for a person. These are exactly the errors where auto-retry would just fail again or duplicate a record.
- 05Runbook lookup: the system owner opens the matching runbook entry for that error signature before acting.
- 06Approve destructive action: any retry that could duplicate a record, or any manual record-level correction, needs system-owner sign-off.
- 07Close and log: resolved errors are logged against their classification, so a recurring signature becomes a permanent fix instead of a repeat alert.
What this looks like in practice
A typical case: a flow fails because a channel sent a malformed SKU. Classified as a data error, it is held rather than retried; retrying would just fail again. The system owner opens the runbook entry for malformed-SKU errors, corrects the source data or the mapping, and clears the queue, with any record-level correction routed through the standard approval gate.
Ready to convert this workflow?
Altura can help map the current state, define controls, and decide whether this should become integration work, automation, AI assistance, or a productized path.