Most "Integration Errors" Are Data Errors in a Costume

The integrations worked.

That is the uncomfortable finding, because on this programme roughly nine out of ten things logged as "integration errors" were not integration errors at all.

They were data.

What It Looks Like From the Outside

Salesforce confirms a postcode is Ready For Service. The journey starts. Halfway through, the process fails.

The tester sees an error from the provisioning system. It says something technical, it mentions the integration, and the obvious conclusion is that the callout is broken.

It is not. The service at that address is already live in the provisioning system. Salesforce's view and the downstream reality disagree, and the record has to be deleted before anything can proceed.

Deleted by whom? Not the tester. Not the team. An external support function, with no service-level agreement and, on one occasion I measured, about twenty-four hours of turnaround for a VoIP case.

That is a day of execution parked, and none of it has anything to do with the API.

Why Juniors Lose Days Here

Someone new sees "integration error" and starts debugging the integration. Logs, payloads, endpoint configuration, retry behaviour. It is the reasonable move, and it is the wrong one, because the error message describes the symptom's location rather than its cause.

Worse, in the higher environments the usual escape hatch is closed. You often cannot simulate around a bad data state with a tool of your own, so you cannot even prove your theory quickly. You wait for someone else, in another team, who has no commitment to your sprint.

The Diagnostic Question

Before you debug an integration, ask one thing:

Is this a message the integration produced because it worked correctly on bad data — or because it failed?

An integration that correctly reports "this service already exists" is functioning. It is telling you the truth about a state you did not expect. That is a data problem with an integration-shaped error message.

Three follow-ups that resolve almost every case:

• What does the downstream system believe about this record right now? Not what Salesforce believes. Go and look, or get someone to look.
• Who can change that state, and how long do they take? If the answer is another team without an SLA, you have found the real constraint on your test execution.
• Has this exact data been used before? Reused test data carries state. A record that passed through half a journey last week is not a clean starting point this week, however clean it looks on screen.

Treat the Data Dependency as a First-Class Risk

This is the part that matters for a test lead, and it rarely appears in a test strategy.

An external data-reset dependency with no SLA stalls execution more effectively than any code defect. A defect gets a priority, an owner and a fix. A data request gets a queue position.

So put it in the plan where it belongs:

• Name it as a risk in the test plan, with the measured turnaround time rather than an estimate. "VoIP data reset: ~24h, external team, no SLA" is a sentence that changes how a schedule gets built.
• Track blocked hours. Not complaints — hours. One row per incident: what was blocked, what state caused it, who unblocked it, how long it took. After a few sprints you have a number, and a number is arguable in a way that frustration is not.
• Build a pre-flight data check into the test itself. Before the journey starts, assert the starting state in every system it will touch. A test that begins by proving its own preconditions fails in the first thirty seconds instead of the fifteenth minute, and it fails with a clear reason.
• Ask who owns the reconciliation. If two systems can disagree about whether a service exists, somebody should own detecting that drift. Usually nobody does, and that is a finding in its own right — one worth raising outside the defect board, because it is an operational gap and not a bug.

What This Changes About Blame

There is a cultural side effect worth naming.

When "integration error" is the default label, the integration team spends its time defending work that is not broken, and the testing team spends its time waiting for fixes that were never needed. Both groups end up believing the other is the problem.

Relabelling these correctly — as data-state failures with an owner and a turnaround time — does more for the working relationship than any process change. It moves the conversation from "your API is unreliable" to "our test data has no owner," which happens to be both true and fixable.

How many of the integration defects on your board this sprint would survive the question: did the integration fail, or did it correctly report bad data?