The question this module answers: Why do real solutions combine several patterns, and how do you put them together?
So far, one arrow has had one pattern. Real solutions aren’t like that. Sometimes you don’t just use one integration method. Here’s a design we took to production that used four.
The company had five Salesforce orgs, one per business line: electrical, plumbing, heating, roofing and solar. Some of it came from acquisitions, and each line ran its own business. But if you were selling plumbing, you wanted to see what cases and opportunities the customer had with electrical. You didn’t want to copy it into your org. You just wanted to see it.
That’s data virtualization, module 3, and Salesforce Connect does it: it can even read another Salesforce org. So the first answer is easy: every org connects to every other org, each with its own Salesforce Connect connection.
Now count. Electrical needs to see plumbing, heating, roofing and solar: four connections. So does plumbing, and heating, and roofing, and solar. Five times four is 20 connections. Salesforce Connect is “available for an extra cost” (Salesforce Connect (opens in a new tab), Salesforce Help, checked 2026-11-01). That’s a lot of licensing, and twenty of anything gets costly.
It’s the same arithmetic you met in chapter 5: point to point grows with every pair.
And money isn’t the only problem. Salesforce Connect adds a related list for each connection, at the object level. Pick one org, say electrical, and open an account. There’s electrical’s own Cases. Then plumbing’s cases, an external object through its own connection. Then heating’s, then roofing’s, then solar’s: four separate external objects for one idea, a case, and four related lists of cases on one page.
Frame 1 of 2: one page, every pair. Four related lists of cases from four other orgs.
Your users see four lists where they want one. Your reports have to combine four objects. Then do it all again for opportunities, and for orders. And every new org adds one more external object to every other org. So we chose not to use Salesforce Connect between every pair.
So we put a database in the middle, our mini data lake: one shared database with every org’s cases and opportunities. Now every org connects to one place, and the order you build it in matters.
First, set your baseline. Change Data Capture only sends new changes, so the database starts empty of everything that already happened. A Bulk API load copies each org’s existing records into it, once. The load process calls in to each org, so its arrows point back in.
Then keep it in sync. Change Data Capture in every org, and a listener that subscribes to each one. These arrows point back in too: the listener opens the connection to subscribe, even though the changes flow out to the database. That’s the reversed arrow, and chapter 11 (coming soon) takes it apart.
Frame 4 of 4: five Salesforce Connect connections, not twenty.
And now go back to electrical’s account page. One related list of cases from every other line. The shared database holds electrical’s cases too, so they’re filtered out of that list: if you’re in electrical, you see plumbing, heating, roofing and solar, and your own cases stay where they are.
Seed it. If an org has 100,000 opportunities and you turn on Change Data Capture, none of the past ones reach the database. So first a process with the Bulk API extracts them and pushes them into the database. That’s Batch Data Synchronization, used once, to set the baseline.
Keep it current. Then you turn on Change Data Capture in every org. It “publishes events for changes in Salesforce records corresponding to create, update, delete, and undelete operations,” in Salesforce’s words, so nobody has to build the event. A listener subscribes and writes each change to the database. That’s publish and subscribe, module 4, and to each org it’s a fire and forget. You could write your own flow and publish your own platform events, or go old school with outbound messages. Change Data Capture just does it for you.
See it. Each org’s Salesforce Connect reads the database when someone looks. One external object, with every other line’s records on it, not four. That’s Data Virtualization.
Catch what was missed. And then a nightly refresh, or a weekly one, catches the one in a billion transaction that didn’t make it. That’s Batch Data Synchronization again, as the backup plan from module 5.
Four pieces, four patterns: a batch to seed it, events to keep it current, virtualization to see it, and a batch underneath to keep it honest.
Here’s the test of a design: what happens when it grows? A sixth business line arrives. With every org connected to every other, six orgs need 30 connections, ten more, and every existing org gets one more related list.
With the database in the middle, you just plug it in, in the same order:
Bulk load its existing records into the database, to set its baseline.
Set up Change Data Capture going out, and subscribe the listener, so it stays in sync.
Turn on Salesforce Connect: one more connection, to the database.
Nobody else changes anything. The other five orgs already read the database, so the sixth line’s cases simply appear in the related list they already have.
These parts aren’t only one team’s idea. Salesforce is retiring Salesforce-to-Salesforce, its older way of sharing records between orgs, in Spring ‘27, and its guide names the replacements: Salesforce Connect, Change Data Capture or Pub/Sub API (Integration Patterns (opens in a new tab), the legacy table, checked 2026-11-01). The same parts as this design. How they fit together for several orgs is the multi-org chapter (coming soon).
For every need: whether one pattern is enough, or it takes several.
For every combination: which pattern does which job: seed, keep current, show, and catch what was missed.
For every design: what happens when it grows by one, and how many connections that adds.
For every event-driven piece: the batch that seeds it, and the batch that backs it up.
For every build: the order. Set the baseline, keep it in sync, then let people see it.
Beyond the exam: what AI changes. Ask an AI to design this and you’ll likely get the first answer: connect every org to every other org. It’s correct, and it’s the one that doesn’t grow. The second answer comes from counting, the related lists, and asking what happens with org number six. Give it those questions, and it does much better. But the questions are the design work.
