An integration that drops invalid records can appear healthy while important work disappears. A quarantine is a controlled place for records that cannot yet be accepted. Its purpose is to make the problem visible and give an authorized person a safe path to resolution.
Related service: Custom software development- 01Validate structure and business rules.
- 02Isolate the failed record with its reason.
- 03Assign and investigate the exception.
- 04Correct through an authorized route.
- 05Revalidate and reconcile the final outcome.
SECTION 01
Separate structural errors from business exceptions
A missing identifier, an invalid date and an unknown product need different explanations. Some failures can be corrected at the source; others need a business decision. Avoid one generic Failed label that leaves operators guessing. Define whether a single bad row blocks the whole batch or whether valid rows may continue with an explicit partial result.
JSON Schema provides structural validation concepts, while database constraints can protect required relationships and uniqueness. These controls complement rather than replace workflow-level checks. A record can have valid fields but refer to a discontinued product or a closed operational period. The responsible owner must decide how that business exception is handled.
SECTION 02
Illustrative example: a shipment references an unknown item
Imagine a shipment feed contains an item code that has not yet reached the product system. The integration keeps the shipment in a restricted exception queue and explains the missing reference. It does not silently replace the code with a default product or discard the shipment while reporting the entire feed as complete.
Once the approved product record arrives, an operator or controlled retry revalidates the shipment. If the original source sends it again, identity rules connect it to the pending exception rather than creating two shipments. This planning example shows why retained evidence, ownership and retry behavior belong together in the development scope.
SECTION 03
Make the queue usable and bounded
Show the age, reason, source and responsible team for pending records. Restrict raw payload access and redact sensitive values from general alerts. Agree retention and cleanup so unresolved exceptions do not become a permanent hidden copy of customer data. Escalate old or repeated failures through an owned process.
Acceptance should demonstrate a rejected record, a correction, a repeated retry and the resulting reconciliation totals. Record any manual override with its authority and reason. Start with the common failure categories and an escalation route for unfamiliar cases. An elaborate review dashboard is not useful if no one can explain which records remain unresolved at the end of a run.
SECTION 04
Frequently asked questions
Should every invalid row stop the entire import?
Only when the business requires an all-or-nothing result. Otherwise, make partial acceptance explicit and reconcile every rejected or pending record.
Can staff edit quarantined records freely?
No. Define permitted corrections, preserve source evidence where appropriate and record who authorized an override.
What should happen after a correction?
The record should pass through normal validation and duplicate controls again, with its final outcome linked to the original exception.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Object validation rulesJSON Schema
- Database integrity constraintsPostgreSQL
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy