OIC error handling that people can act on
Most integration failures are not technical mysteries. They are business exceptions nobody routed to the right person. Here is the pattern we use on every OIC estate.
By AMTEX Consulting · Editorial
When an OIC integration fails, three questions need answering within minutes: what business record was affected, who needs to know, and can it be resubmitted safely. Most estates can answer none of them without a developer opening the instance tracking page.
Separate technical faults from business exceptions
A timeout calling Fusion is a technical fault. A supplier that does not exist in Fusion is a business exception. They need different audiences and different handling. We model both explicitly: the global fault handler catches technical faults, and the integration raises a typed business fault for anything a user could fix.
Carry business identifiers as tracking variables
Invoice number, employee number, purchase order. Set them as tracking variables at the start of the flow so they appear in monitoring and in every notification. An alert that says 'Integration X failed' is noise. An alert that says 'Invoice 10442 for Supplier ACME rejected: supplier site inactive' is work someone can do.
Route to people, not mailboxes
- Technical faults go to the integration support queue with the instance id and a link.
- Business exceptions go to the owning team with the record identifiers and the fix.
- Repeated faults within a window are aggregated into a single digest to avoid alert fatigue.
Make resubmission safe
Resubmitting a flow that already created half its records duplicates data. Idempotency keys on every create, upserts where the target supports them, and a check-before-write on the ones that do not. Then resubmission becomes a button a support analyst can press.
- oic
- error-handling
- monitoring