Combining Mechanisms, and Licensing Them
Module 5 of 7 in the chapter Choosing the Right Integration Design, chapter 16 of the Integration Architect course. Each module stands on its own. Previous: Trade-offs, the Course’s Way · Next: Write the Design Down
The question this module answers: When one design combines several mechanisms, how do you decide which part gets which, and how do you count what it costs?
Most Designs Are More Than One Mechanism
Section titled “Most Designs Are More Than One Mechanism”Chapter 7 told the story of five business lines, five Salesforce orgs, that wanted to see each other’s cases and opportunities (chapter 7 module 6). The answer used four mechanisms: a Bulk API load to seed one shared database, Change Data Capture to keep it current, Salesforce Connect to read it, and a nightly batch to catch what was missed. Salesforce’s own decision guide describes the same shape for several orgs: one database in the middle, read back through Salesforce Connect.
That’s normal. A real design is rarely one mechanism. It’s several, each doing the part it’s best at. The skill is deciding which part of the data goes through which, and then counting what the whole thing costs, because the cost of a combination isn’t always what you expect.
A Hybrid: Act on a Copy, Look at the Rest
Section titled “A Hybrid: Act on a Copy, Look at the Rest”Here’s another one of mine. A customer had a sales system with tens to hundreds of millions of order records, and they wanted all of it available in Salesforce.
Bring hundreds of millions of rows into Salesforce? That’s the large data volume problem the decision guide warns about: “Unless the data absolutely needs to reside in Salesforce, consider data virtualization with Salesforce Connect instead.” But leaving it all outside wasn’t right either. People needed to search for orders, and work with them, in Salesforce.
So we split it. The data went onto a database Salesforce could reach, and Salesforce Connect showed it as external objects. Then some of the records came in as local records, so people could search them in Salesforce: more or less the order headers. The order details, the long tail of rows, stayed in the external database, and Salesforce Connect showed them when someone opened an order. It was a hybrid.
Copy what people search and act on. Look at the rest.
The rule I took from it: copy what people search and act on; leave outside what they only look at. The headers are few, people find orders by them, and they’re the records automation and reports need. The details are many, and people only read them once they’ve found the order. Two mechanisms, a copy and a view, split along the line of what people actually do with the data.
How Salesforce Connect does the looking, its adapters, and more hybrids are chapter 19 (coming soon). The data side, copy or virtualize, is in the Data Architect course (Virtualization (coming soon)).
Do the Licence Math
Section titled “Do the Licence Math”Salesforce Connect is an add-on, “available for an extra cost” in Enterprise, Performance and Unlimited Editions. How it’s counted matters more than the price, so read the counting rule carefully (Salesforce Connect Adapters Included per Add-On License (opens in a new tab), checked 2026-11-07):
- A licence “is associated with a single Salesforce org.” An org that reads needs its own.
- Each licence includes 5 cross-org connections, plus 1 connection of any other kind: OData 2.0, 4.0 or 4.01, a custom Apex adapter, DynamoDB, SQL or GraphQL.
So the hybrid above needs one licence: one org, one connection to one database.
Now recount the five orgs with today’s table. In chapter 7 we counted connections: every org reading every other org is 20. Here’s the licence math.
Same licences today. Not the same design.
Every pair: each org reads four others, and four cross-org connections fit inside one licence. Five orgs, five licences.
One shared database: each org has one connection, to the database. Five orgs, five licences.
The same number of licences. That surprised me when I first did it with today’s table, and it’s exactly why you do the math instead of assuming it. The shared database is still the better design, but for other reasons, and they’re worth saying precisely:
- 20 connections against 5. Twenty things to set up, secure and keep running, against five. And a sixth org adds ten more connections to the mesh (it reads five orgs, and five orgs read it), but one to the database.
- One related list instead of four. The users see one list of cases, not one per org (chapter 7’s two frames).
- Whose allocation pays. With the cross-org adapter, “each callout counts towards the API usage limits of the provider org” (General Limits for Salesforce Connect (opens in a new tab), checked 2026-11-07). In the mesh, every page someone opens in plumbing spends API calls in heating, roofing and solar. With the database, the reads go to the database. It has to take the load, but no org pays for another org’s curiosity.
The rule: count connections per adapter type, per org, then licences per org, then whose API allocation every read spends. And read the table on the day you design, because it’s the table that decides, not last year’s memory of it.
The Limits That Shape a Hybrid
Section titled “The Limits That Shape a Hybrid”At hundreds of millions of rows, Salesforce Connect’s limits aren’t small print. These are the ones that shaped designs like the hybrid, as Salesforce Help gives them on 2026-11-04 (General Limits for Salesforce Connect (opens in a new tab); General Limits for Salesforce Connect OData Adapters (opens in a new tab)):
| Limit | Value | Why it matters |
|---|---|---|
| New rows retrieved or created per hour | 100,000 | Not on Hyperforce (from Spring ‘25, rolling out) or for high data volume sources. A busy view of a large table can reach it. |
| New record IDs per hour, OData 2.0 and 4.0 | 100,000 (long-term), 100,000 (short-term) | Removed for OData 4.01 since Spring ‘25, on Hyperforce, rolling out. For a large external table, choose 4.01. |
| OData request and response | 8 MB each | Keep each answer small: ask for what’s on the screen. |
| OData result set | 16 MB per query | Same: page and filter at the source. |
| Server-driven paging | 2,000 rows a page | The external system should page its answers. |
| Joins per query | 4 | Can affect reports and dashboards. |
| External objects per org | 200 | Counted apart from custom objects. |
Three more things from the same pages. The OData adapters have “no callout limits,” but “the external system may have its own limits”: the database you point at has to take the traffic. The SQL, DynamoDB and GraphQL adapters have no callout limits either, but “callouts can incur charges from the hosting provider”: the running cost may land on another bill. And when OData calls hit rate limits, Salesforce’s first suggestion is to “Select High Data Volume in the external data source definition. Doing so bypasses most rate limits, but some special behaviors and limitations apply.” Chapter 19 takes those behaviours one at a time.
Test knowledge. Know when to virtualize instead of copying: large volumes that people look at but don’t need to report on or automate, data that must stay in another system, and combinations where the searchable part is copied and the rest is viewed through Salesforce Connect. Know that Salesforce Connect is a paid add-on, licensed per org and per connection, and that the cross-org adapter’s calls count against the API limits of the org being read.
Beyond the exam: what AI changes. Ask an AI assistant to count licences for a design and it will happily do arithmetic on whatever rule it remembers. The rule changes; it’s a table on a Help page. Give the assistant today’s table, and ask it to count connections per adapter type per org, then licences per org, then whose API allocation each read spends. It’s very good at that once it has the right rule, and it shows its working, which is what you need to check.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- Which data is copied and which is viewed, split by what people search and act on.
- The licence count, from connections per adapter type per org, on today’s table.
- Whose API allocation every read spends, and whether the external system can take the load.
- Which limits shape the design: the OData version, high data volume, page sizes, and the hourly limits.
Explore
Section titled “Explore”- Salesforce Help, Salesforce Connect Adapters Included per Add-On License (opens in a new tab) (checked 2026-11-07).
- Salesforce Help, General Limits for Salesforce Connect (opens in a new tab) and General Limits for Salesforce Connect OData Adapters (opens in a new tab) (checked 2026-11-07).
- Several Patterns, One Solution: chapter 7, the five orgs in full.
- Data Connectivity and Virtualization (coming soon): chapter 19, Salesforce Connect in depth.