Integrated case: handling exceptions without hiding the evidence

ERP exceptions can arise from incomplete data, failed requests, configuration differences or real business disagreements. The appropriate response begins by identifying what succeeded, what failed and which record is authoritative. Repeating an operation blindly can make a partial result harder to reconcile.

Northstar encounters several issues during a busy period: an import reports skipped rows, a dependency is missing from a task and an integration delivery needs attention. These issues require different evidence and recovery actions.

Distinguish partial outcomes

DNA's import service tracks successful, failed and skipped records. A lookup-loading failure can also leave some references unchecked. The team should reconcile the result to the source file before retrying.

Task creation and dependency creation use separate requests in the reviewed flow. A saved task does not prove that every dependency saved. Similarly, an integration connection can exist even if its optional key or webhook creation failed.

Investigate the relevant evidence

DNA's delivery logs allow replay requests, but re-queuing is different from successful destination processing. The reviewed bulk summary does not establish each individual replay result. Examine the relevant delivery outcomes and the receiving system's records.

Audit evidence also has scope. The reviewed general Audit Reports logger is local and bounded, while AI Audit has a separate API source. Neither should be used to invent a complete history beyond its available records.

Preserve a clear recovery record

A useful recovery note states the affected records, observed result, reason for the action and verification after it. The business should know which data was corrected and which uncertainty remains.

This review helps complete failed work without repeating what succeeded. Keep any uncertain outcome visible until the relevant records resolve it.