Learn 06 · Integration · retries · data
The integration says success. The record is wrong.
Follow one event through to the actual business result.
Where was success reported?
At the sender, an integration layer, the Salesforce response or the final record? State exactly what that signal confirms.
Follow one event
Collect the source identifier, target identifier, times, expected value and actual value. Keep credentials and customer details out of the worksheet.
Separate the symptom
Missing record, duplicate record, wrong value, delayed update and an old event overwriting a new value lead to different investigations.
Compare two explanations
The wrong value arrived in the payload: inspect the source value and field mapping for this event.
The expected value arrived, then changed: inspect later writes, event order and retries. Do not change the mapping just because the final value is wrong.
Make the contract visible
For each step: expected input, identifier, expected result, evidence, responsible role and failure path. A missing trace is a finding to resolve before claiming a root cause.
Test more than the happy path
Agree expected outcomes for an ordinary event, a duplicate, a delayed event and a rejected update. Decide what retrying should do before the pilot.
When should the design change?
Only when the evidence supports a specific explanation. Change one thing in a suitable test environment, compare expected and actual final states, and define when to stop or roll back. An accepted request alone is not evidence that the business job finished.
Take this to your next conversation
What did we observe? What else could explain it? Which one check would separate the explanations? Who can check it? What result would make us change our plan?
Fictional learning example. No systems are inspected, no configuration is changed, and no business outcome is verified.