A Salesforce Integration Usually Fails in the Scoping Call, Not the Build

A Salesforce integration project rarely dies during the build. It dies earlier, in the scoping conversation where a specific question went unanswered, and the build simply inherited whatever assumption filled the silence - a sync frequency nobody actually agreed to, a shared field nobody named an owner for, an authentication method chosen because it was already open in a browser tab. By the time it breaks in production, whoever's debugging it is reverse-engineering a decision that was never made out loud in the first place.

Most of the integration work that reaches CloudAvant starts after one of these assumptions has already broken. A Salesforce-SAP sync that "keeps breaking" usually turns out to be a field nobody ever named an owner for, not a flaky connector. That pattern is common enough to say plainly: a lot of what gets diagnosed as an integration bug during production support was actually a scoping decision nobody insisted on making before the first line of code. The seven questions below are the ones worth asking before you build a Salesforce integration, not after it's already live and something's gone quietly wrong.

It's also the gap a Salesforce Health & Roadmap review keeps finding on the integration side specifically - not a technology problem, but a documented absence of decisions: no named system of record, no agreed failure-visibility plan, no owner once the person who built it has moved on. None of that shows up in a demo. All of it shows up roughly eighteen months later.

The short answer

In brief: a Salesforce integration's biggest risks are rarely technical by the time anyone notices them - they're scoping decisions made implicitly, by default, because answering them explicitly wasn't formally anyone's job. Before scoping a build, agree who owns the data, check whether a native connector already covers the need, decide the sync pattern deliberately rather than defaulting to whatever sounds current, choose and name an owner for the authentication model, agree what "failed" actually means and who gets told, and name who supports the integration after whoever built it has moved to the next project. None of this is expensive to answer in a scoping call. All of it is expensive to answer for the first time during a production incident.

Why this is a scoping problem, not a build problem

Ask an experienced Salesforce architect what actually breaks a live integration, and the honest answer is rarely "the API" or "the platform." Salesforce's APIs, for the most part, do what their documentation says. What breaks is the thing nobody wrote down: which system is allowed to win when two systems disagree, how urgently a delay actually costs money versus merely feels slow, who notices when a sync goes quiet. None of those are implementation details a developer can resolve alone, and none of them get easier to answer six months into a build than they were in the scoping call.

That's a specific, falsifiable claim, not a hedge - and it has a direct consequence for how integration work should actually be scoped. A technically excellent build on top of an unmade decision is still a liability; a technically ordinary build on top of a deliberately made one is usually fine. The questions below are ordered roughly by how early they need an answer, not by technical difficulty.

The questions to ask before a Salesforce integration gets scoped

1. Name the data owner before you name the sync

Most "the integration keeps breaking" tickets aren't integration bugs at all - they're an unresolved question about which system is allowed to be right when Salesforce and the other system disagree about a field. We've written about this pattern in detail: a field that reliably reverts to the wrong value is almost always a sign nobody ever decided which system owns it, not a flaky sync. The fix at scoping time is close to embarrassingly simple compared with the fix after go-live - write down, for every shared field, which system wins. It takes an afternoon before the build starts. It takes a production incident and a trust problem with the business afterward.

2. Check AppExchange before anyone estimates a custom build

A surprising share of custom-integration estimates get written before anyone has checked whether a native connector or an AppExchange package already does the job. A vendor-built connector costs nothing to maintain beyond a subscription, and its support doesn't depend on whoever built your custom version still working at the company. A custom build buys flexibility at the cost of becoming something your own team owns forever, including every upstream API change the vendor's broader customer base never has to think about. That trade-off is sometimes genuinely worth it - a bespoke workflow, or a system nobody's built a connector for, is a legitimate reason to build. "Nobody checked" is not a reason. A ten-minute AppExchange search before the first estimate is cheaper than discovering the gap six weeks into a build.

3. Run it by hand once before you automate it

Teams that scope integrations well tend to share one habit: someone ran the process manually, end to end, including its exceptions, before anyone wrote a line of automation. That surfaces two things a requirements document rarely does on its own - whether the process is actually worth automating at all, and the undocumented transformations a person applies without consciously thinking about them (a status quietly renamed, a currency converted, a duplicate merged by eye). Automating around a transformation nobody wrote down is how a "simple" field-mapping integration becomes the one everyone's afraid to touch six months later.

4. Separate "feels slow" from "is actually slow"

"The sales team shouldn't have to wait until tonight" is a feeling, not a figure - and it's the single most common reason teams reach for real-time integration patterns they then don't monitor properly. The actual decision framework is worth walking through separately: real-time earns its added operational cost - idempotent processing, dead-letter handling, someone actually watching event delivery allocation - only where a specific, named business cost is measured in minutes, a fraud hold or a stock level hitting zero, not simply where a stakeholder would prefer it. Ask for the number before agreeing to the pattern.

5. Own the authentication method on purpose

Authentication tends to get decided by whatever was fastest to wire up during the proof of concept, then never revisited - and that's a real, current cost, not a hypothetical one. Salesforce's own named credentials documentation confirms that, since February 2026, named credentials added inside a managed package now default to developer control rather than admin control: a deliberate tightening of who can see or change a credential, and a reminder that authentication configuration isn't a "set it once" artifact even on Salesforce's own roadmap. Decide, at scoping time, who owns the Named Credential or External Client App for this specific integration, and record that ownership somewhere other than one person's memory - the kind of single point of failure we've covered separately. If the integration needs its own login rather than riding on a human user's credentials, a scoped Integration User license is usually the right call, not a shared admin account nobody can safely rotate.

6. Agree what "failed" means before go-live, not after

A sync that returns a success response while quietly dropping records looks, from the outside, identical to one that's working - exactly the trap in real-time integration's main failure mode. Before go-live, agree explicitly what "failed" means for this specific integration, which signal will actually catch it (an error log alone usually isn't enough), and who gets paged when it fires. An integration with no agreed failure definition isn't more reliable than one with a badly chosen one - it's just one where nobody finds out until a customer, or a quarterly report, does.

7. Name the second owner before the first one leaves

Every integration eventually outlives the person who built it - a contractor's engagement ends, a developer changes teams, a partner gets switched out. Decide at scoping time who inherits it, and make sure that person or team has visibility into it well before the handover is forced by someone's resignation letter. An integration with no named second owner isn't a risk that might materialise later - it's a liability with a deferred due date.

What happens when these go unanswered

Questions worth asking about this list itself

Isn't this just a project-management checklist?

Not quite. A project-management checklist asks about timeline, budget, and resourcing. These seven are architecture and governance decisions specifically - the kind a project plan usually has no line item for, and the kind that determine whether the thing being built is still supportable in year two, not whether it ships on time this quarter.

We're using an iPaaS like MuleSoft or Boomi - do we still need to answer these?

Yes, arguably more so. Middleware changes where the integration logic and error handling live, not whether these decisions get made - a well-governed iPaaS platform still needs someone to name the system of record, agree the failure-visibility plan, and own the authentication model for each connection running through it. The platform doesn't make those decisions for you; it just gives you a better place to implement them once they're made.

How long should scoping these actually take?

For most point-to-point integrations, a half-day working session with the right people in the room: the business process owner, whoever currently does the work manually if it's being automated, and whoever will support the integration afterward. The cost here isn't the time itself - it's remembering to schedule that session before a developer is already assigned and a delivery date is already quoted.

What if we've already built the integration and never answered these?

Then they're worth answering now, retroactively, rather than waiting for the gap to surface as an incident - which is exactly what a Salesforce Health & Roadmap review's integration section is designed to do for integrations already running in production.

The bottom line

None of these seven questions require a new tool, a bigger budget, or a longer timeline. They require someone with the standing to insist they get answered before a developer opens a sandbox. Most Salesforce integrations that eventually show up as a "this keeps breaking" ticket were never actually broken in a technical sense - they were scoped with a gap where a decision should have been, and real volume, a departure, or a schema change eventually found it. If you're scoping one now and aren't sure your team has the standing to insist on these answers before a vendor or developer starts building, we're happy to sit in on that scoping conversation with you - cheaper, always, than sitting in on the incident call six months later.