Your Salesforce Integration Keeps Breaking. The Data Was Never the Problem.

"The integration keeps breaking" is usually the first sentence in a ticket like this one - and it's usually the wrong diagnosis. A handful of account records show the wrong status every few weeks, always on accounts both systems touch, always logged as "the sync glitching again." Someone reruns the job, the numbers look right for a while, and the ticket closes as resolved. Six weeks later it's back. That loop - glitch, rerun, close, repeat - is a genuinely common shape a system-of-record problem takes before anyone names it correctly. It doesn't announce itself as an architecture question; it shows up as a recurring support ticket, which is exactly why it can sit unresolved for months before anyone treats it as the decision it actually is, rather than a bug to patch again. A Salesforce Health & Roadmap review's integration section is built to ask exactly the question a ticket queue never does.

What "the integration keeps breaking" usually means

The obvious suspect is always the integration job itself: a flaky nightly batch, a timing gap between the SAP export and the Salesforce import, a field mapping that's drifted since the last SAP upgrade. Whoever gets paged treats it as exactly that - a sync bug - because from inside a single ticket, that is what it looks like. The team reruns the job, checks the error log for a stack trace, maybe adds a retry. All of that is reasonable triage. None of it asks the one question that actually explains a value that keeps reverting on a schedule: which system was supposed to win when both Salesforce and SAP have a legitimate, recent update to the same field? Point-to-point SAP connections built by different people at different times tend to accumulate for years without anyone auditing exactly which interface they call or who's supposed to own what - a gap we've written about separately in the context of SAP's 2026 API policy change - and this kind of ownership question is usually the older, quieter version of the same underlying problem.

What the investigation actually found

Pull the audit trail on one of the reverting records and the pattern is usually visible within the hour. A sales rep updates the account's status in Salesforce during the day. That night, a scheduled SAP-side export job re-runs on its usual timetable and pushes SAP's own value for the same field back into Salesforce - not because anything went wrong, but because nothing in the job was ever told the Salesforce edit had happened. It just does what it always does. Salesforce accepts the update, because nothing in the integration says it shouldn't. The rep's change is gone by morning, silently, with no error anywhere - the sync didn't fail; it did exactly what it was built to do. Multiply that by however many fields both systems happen to write to, and "the integration is unreliable" becomes the working theory, even though every individual sync ran successfully.

The underlying issue: nobody had decided who owns the field

The sync wasn't broken. It was doing precisely what it was configured to do - export on schedule, write the value it received. What was missing was a decision that should have been made once, at design time, and never was: for this specific field, which system is the system of record, and what happens when the other system also has a legitimate, competing update. Nobody built that logic because nobody was ever explicitly asked the question. The original integration got scoped around "sync accounts between Salesforce and SAP," which sounds complete and isn't - it describes a data flow, not an ownership rule. That gap is invisible on a design document and completely obvious in production, which is exactly why it tends to surface as a support ticket instead of an architecture review.

What actually fixed it

Once the pattern is named correctly, the fix is almost boring by comparison to how long the problem lasted. It's rarely a rebuild - it's a decision, enforced, not just documented and hoped for.

1. Name one system of record per contested field. In this pattern, SAP kept ownership of billing and account-status data sourced from ERP records; Salesforce kept ownership of anything a sales or service rep needed to update directly.
2. Make the non-owning system read-only for that field wherever possible - a validation rule or page-layout restriction in Salesforce, rather than relying on people remembering not to edit it.
3. Where a field genuinely needs to stay editable from both sides, which does happen, add an explicit last-writer timestamp and a defined conflict rule, instead of letting "whichever job ran most recently" be the unwritten rule.
4. Write the decision down somewhere other than the code - a short mapping document naming the owning system per shared field, because the next person maintaining this integration shouldn't have to reverse-engineer the rule from behaviour.

The architect's takeaway

Most "unreliable integration" complaints aren't actually about reliability - a job that runs on schedule and completes without error is reliable by definition. They're about a decision that got skipped during design and is now surfacing as behaviour nobody predicted. That's worth saying plainly, because it cuts against the instinct to fix data-conflict symptoms by making the integration cleverer: more retries, more error handling, a smarter merge algorithm. None of that helps if the real gap is that nobody decided which system's answer counts. A merge algorithm is a technical answer to what is, underneath, an organisational question - and an unusually cheap one to answer, if someone actually asks it before the integration ships rather than after it's been in production for two years.

This isn't true of every recurring sync issue, and treating every glitch as a governance failure is its own kind of overcorrection. The distinguishing signal is in the table above: a genuine bug is intermittent and unpredictable; an ownership gap is consistent and explainable, once you know where to look.

A few questions worth asking before the next rerun

Is every recurring Salesforce-SAP sync issue actually an ownership problem?

No - and treating every glitch as a governance failure is a mistake in the other direction. Genuine timing and race-condition bugs exist and deserve a technical fix, not a governance meeting. The tell is consistency: an ownership gap produces the same field reverting the same way, over and over, on records both systems touch. A real bug is usually messier and less predictable than that.

Why not just add better error handling or retries instead?

Because the sync isn't erroring - that's what makes this pattern hard to spot from inside a ticket queue. Both systems completed their jobs successfully; they just each wrote a value the other considered correct. More retries make a genuinely broken job more resilient. They do nothing for two systems that are each working exactly as configured and disagreeing anyway.

How do we find this before it turns into a support ticket?

Ask, for every field both systems can write to, which one wins - during the integration's design, not after go-live. If that question was never asked, and on any integration built before this became a standard checklist item there's a decent chance it wasn't, a Salesforce Health & Roadmap review's integration section is built to surface exactly this kind of undocumented ownership gap alongside the rest of an org's technical debt.

The bottom line

A Flow that fails loudly gets fixed quickly, because the error is impossible to ignore. A field that quietly reverts to the wrong value, on a schedule nobody set, is slower and more expensive to catch precisely because it looks like a minor annoyance instead of the actual defect: a decision that was never made. If a Salesforce-SAP - or any two-system - integration in your org has a field that "occasionally glitches" and always seems to resolve itself with a rerun, that's worth a direct look before the next rerun, not after the tenth one. Our senior architects have seen this pattern often enough to know it rarely needs a rebuild, just a decision - get a second opinion if you'd like one.