- Fix the root cause before re-syncing data.
- Choose the narrowest repair that works.
- Preview and audit every repair.
Once you know what is wrong, you may be tempted to retry the failed execution or run a full resync. Either of these may help. However, either may also create duplicates, overwrite valid edits, trigger customer-facing side effects, or otherwise do more damage than good.
Before you get to reconciliation, you need to address the underlying cause. Reconciliation restores data, but it doesn't repair a broken mapping, an expired credential, or a failing API. If the cause remains active, corrected records can be knocked out of sync as soon as the integration runs again.
Classify the failure
Temporary failures (such as timeouts, server errors, and rate limits) may be resolved by retrying after an appropriate delay. Permanent failures (such as a missing required field or invalid value) need a data or configuration change before reprocessing. Repeating a permanently invalid request only repeats the failure.
Choose the narrowest repair
Once you know the cause, implement the narrowest repair to restores the intended state. Why narrow? Because the more things you touch with the repair, the greater likelihood that you'll create an issue elsewhere.
Here are some options that should limit the negative side effects:
- Retry or replay a failed operation when it is safe to repeat.
- Look up the destination record after an uncertain timeout before creating anything again.
- Backfill a known set of affected records.
- Resume from a checkpoint where you know the data was correct.
- When the scope is unclear, compare records on both sides and patch only the differences .
- Route ambiguous or high-impact issues to a human being for detailed examination.
Let the failure determine the fix
For example, if an order reached the ERP and inventory was updated, but the confirmation failed, replaying the whole flow could create another order. Instead, finish the missing step. Here's another example: If a contact was deleted, don't automatically recreate it; first determine whether deletion was intentional and what the customer's rules say. If both systems changed a value, apply an established ownership or conflict rule – or ask the customer (when the right answer depends on business context).
Preview and audit the repair
Before applying a repair, preview the changes and check for newer edits. Throttle large jobs so they don't hit API limits or delay live traffic. Consider side effects, isolate the work to the customer, and keep an audit trail of what changed and why. For financial and other critical records, a human review is usually the best way to go.
Define success
Success means that the affected records now match the intended business state and that this has been achieved without disturbing other data or creating additional issues. If you've solved one issue and created three more, that's not success.
Our next post in this series will focus on designing integrations that make it easier and safer to reach that state when things go wrong.
