- Successful executions don't prove that data is correct. Logs show what the integration attempted and observed, not later edits, events that never arrived, or mis-mapped values.
- Reconciliation targets consistency with business rules, not identical data. An integration may intentionally sync only certain records or fields. A mismatch can also be definitional, such as two systems counting "active" differently.
- Drift shows up in several forms. A record is missing on one side, a retry creates a duplicate, one record is stale or wrong, independent edits disagree, or a child points to a missing parent. Common causes include timeouts, throttling, missed or out-of-order webhooks, partial batches, and customer changes to mappings or credentials.
Your product says your customer has 1,240 active accounts. Your customer's Salesforce says 1,302. Which number is right?
The integration has been running for months, and executions are succeeding. No alert has fired, and no one knows when the systems stopped agreeing.
What is integration drift?
This may be integration drift: connected systems gradually falling out of sync, developing inconsistencies in data that should match. It can result from missed updates, partial failures, mapping changes, or other issues that aren't necessarily reflected in an integration's execution status.
Integration drift is one of the main reasons teams need data reconciliation. That's the process of comparing data across systems, identifying discrepancies, and resolving them according to defined requirements. The last part is really, really important. The goal isn't to make two databases identical – since an integration may intentionally sync only certain records or fields. The goal is consistency with the integration's requirements (business rules).
Forms and causes of drift
Drift takes several forms:
- A record exists on one side but is missing on the other.
- A retry creates a duplicate.
- Both records exist, but one is stale or has an incorrect value.
- Two systems were edited independently and now disagree.
- A child record points to a missing parent, or a deleted record remains in the other system.
The causes are just as varied. APIs time out or throttle requests. Webhooks are missed or arrive out of order (many providers don't guarantee order). A batch partly succeeds. A customer changes a required field, a mapping, or a credential. A direct edit or import bypasses the integration. Sometimes a request succeeds, but a transformation is flawed (creating incorrect output).
Why execution status doesn't tell us enough
That variety is why execution status alone can't prove data correctness. Logs show what the integration attempted and observed. That's it. Often, they don't reveal changes made later, events that never arrived, or values that were mapped incorrectly.
How to investigate data mismatches
When a mismatch surfaces, don't immediately push the resync button (whatever that may be). First establish whether the difference is a problem. It may simply be a definitional mismatch, such as the two systems counting "active" differently. Then determine what is affected: one record, one object, one customer, or many customers. Find the last known-good point, check whether the cause is still active, and identify which system owns the affected data. Finally, consider what a corrective write could trigger – a notification, a new record, or something else.
These questions turn "the numbers don't match" into a problem you can investigate. They also prevent a small repair from masking a larger outage. If three invoices are missing because a nightly batch has been partially failing for weeks, manually creating three invoices doesn't address the thousands of changes that may have been missed.
A good drift investigation ends when you know what caused it and what the data should look like (once it's reconciled).
Our next post in this series will focus on doing the repair that gets data back to where it should be without creating a larger issue.
