Salesforce's Decision Guide, Read Well

Module 2 of 7 in the chapter Choosing the Right Integration Design, chapter 16 of the Integration Architect course. Each module stands on its own. Previous: Pattern First, Then Mechanism · Next: The Forces

The question this module answers: Salesforce publishes its own guide to choosing integration tools. What does it recommend, and how do you read it so it helps your design instead of deciding it for you?

A Guide for “It Depends”

Chapter 7 used Salesforce’s selection tables to choose a pattern (chapter 7 module 5). For the next step, choosing the tool, Salesforce Architects publishes a decision guide: Data Integration with Salesforce (opens in a new tab). It knows what it’s for: “If you’ve uttered the words ‘it depends’ when making integration choices, then you’re in the right place.”

It covers three directions: Salesforce to other systems, other systems to Salesforce, and one Salesforce org to another. For each it compares the tools, low-code to pro-code, and walks through an example. It’s the closest thing to Salesforce’s own opinion on which tool to use, and you should read it before any integration design. Then read it again, the way this module shows.

What It Says Up Front

The guide opens with its main advice. In short, with its own words where they matter:

Don’t copy data you don’t need to. “Unless the data absolutely needs to reside in Salesforce, consider data virtualization with Salesforce Connect instead.” The same goes the other way: let the other system read Salesforce through its APIs rather than keep a copy.
Use what’s already there. If the company has MuleSoft, or another integration platform, “consider whether your existing ESB/ETL solution will suffice.” That’s chapter 6’s constraint, from Salesforce’s side (chapter 6 module 6).
Data 360 to bring data together from several sources, and to move it between orgs.
Be careful with outbound messaging. Salesforce “will continue supporting Outbound Messaging within current functional capacities, but does not plan on making further investments in this technology.” Module 1 met that sentence.
One identity for every integration. “Integration user license with ‘API Only’ profile is always recommended for all integrations,” with External Client Applications “in favor of connected apps or SOAP login.” Chapter 13 built exactly that (module 4, module 6).

And further down, for org to org: “The Salesforce to Salesforce product has reached its end of life” (chapter 7 module 6), and platform events “are not optimal for integrating data from one Salesforce organization to another.”

Primary Tools, and Supporting Ones

Here’s a part people skip. The guide names tools that help with integration but “must not be considered a primary means of solving integration problems”:

Flow: it can call out through External Services or Apex actions, but “Salesforce Flow by itself is not considered a standalone data integration tool.”
Data Import Wizard and Data Loader: good for loading and maintaining data, but “neither of these tools is a recommended base for a data integration strategy.”
The Salesforce CLI: handy for moving records, but not “a standalone data integration tool.”
Lightning Web Components: they can call out, but they “are typically used for process integrations.”

None of that says don’t use them. Chapter 4 built integrations with Flow, and chapter 9 ran callouts from it. It says: if your design rests on one of these as the whole integration, a nightly Data Loader script on someone’s laptop, for example, you need a reason you can defend.

Five Habits for Reading It Well

A decision guide is a strong source. It isn’t the last word. Here’s how I’d read it.

1. Read the legend. The overview table marks each tool, for each direction, as available, “Not Ideal: possible but consider an alternative tool,” or “Not Available: no plans to support in the next twelve months.” That last one is a statement about the next twelve months, made on a date you can’t see. Treat it as Salesforce’s direction, not a permanent fact.

2. Read the footnotes. The same tool can look different in two tables. In the overview, Change Data Capture needs no extra licence, with a star: “Add-on required for high-volume change data capture event use cases.” In the table of low-code tools for sending data out, the same Change Data Capture says “Required.” Both are true, for different volumes. Without the add-on you can choose up to five objects (chapter 11 module 3). The footnote, and the product’s own page, tell you which row is yours.

Click to enlarge

When two rows disagree, read the footnote.

3. Read it with a date. The guide has no date on the page, so write down the day you read it, as this course does for every source. And watch for sentences that have aged. The guide says Salesforce plans “more decision guides focused on event-driven integration” and process integration. When I checked on 2026-11-07, an Event-Driven Architecture guide already existed, just filed under a different heading. The guide’s own words were behind its own family.

4. Know the family. The Data Integration guide sits beside others that answer the next question. When I checked:

Click to enlarge

The next question is often in another guide.

If the Data Integration guide points you to platform events, the Event-Driven Architecture guide is the next one to read (chapter 11 cites it). If it points you to a background job, read Asynchronous Processing. If the question is whether an agent should run the steps at all, there’s a guide for that too.

5. Check it against the product’s own pages. A decision guide summarizes. The detail lives in each product’s documentation. The guide’s footnote says “OData adapters older than version 4.01 are subject to callout limits”; Salesforce Help says what to do about them, and what the limits are (module 5 has them). When the guide and the product’s page disagree, the product’s page is usually the newer one. Cite the one you used, with its date.

What No Guide Can Tell You

The guide’s own six areas to consider are good questions: existing tools and landscape, data flow, implementation, maintainability, data volume, and limits. But they’re questions. The answers are in your landscape, your team, your numbers and your contract with Salesforce, and no guide has those.

Its examples are general on purpose: an opportunity is won and an order goes to the ERP; a contact changes in the ERP. Yours are Steve Trucking’s manifests, its 200,000 truck readings a day, and its partners who each want status their own way. The guide narrows the tools. Your requirements make the choice. Module 3 takes those six areas one at a time, with Steve Trucking, and module 4 shows how to weigh them.

The guide ends the same way: “Keep this guide in mind and refer to it when you’re planning a new data integration involving Salesforce.” Refer to it. Don’t hand it the decision.

Test knowledge. Know Salesforce’s main recommendations for integration tools: avoid copying data that doesn’t need to be in Salesforce (consider Salesforce Connect); use the integration platform the company already has; prefer an integration user with the API Only profile and External Client Apps; no new investment in outbound messaging; Salesforce to Salesforce has reached end of life. And know which tools are supporting only: Flow, Data Loader and the Data Import Wizard aren’t a base for an integration strategy.

Beyond the exam: what AI changes. Ask an AI assistant which integration tool to use, and it may answer from an older picture: Salesforce to Salesforce, outbound messaging, connected apps. That isn’t the assistant’s fault; it learned from what was written then. So ask it for its source and the source’s date, and check its answer against the guide as it reads today. An assistant that cites the guide, and a person who checks the date, make a good team.

What an Architect Decides Here

Which guides apply to this design: Data Integration, and the next one it points to.
Where the design follows the guide’s advice, and where it doesn’t, with the reason written down.
Whether any supporting tool is carrying an integration on its own, and if so, why that’s acceptable.
The date and source of every recommendation the design relies on.

Explore

Salesforce Architects, Data Integration with Salesforce (opens in a new tab) (checked 2026-11-07).
Salesforce Architects, Platform Decision Guides (opens in a new tab), including Event-Driven Architecture and Asynchronous Processing (checked 2026-11-07).
Salesforce Architects, Data 360 Decision Guides (opens in a new tab) (checked 2026-11-07).