The Forces
Module 3 of 7 in the chapter Choosing the Right Integration Design, chapter 16 of the Integration Architect course. Each module stands on its own. Previous: Salesforce’s Decision Guide, Read Well · Next: Trade-offs, the Course’s Way
The question this module answers: Once you know the pattern, what actually decides which mechanism to use?
Forces, Not a Formula
Section titled “Forces, Not a Formula”Module 1 left a fire and forget with three ways to build it, all of which would work. The pattern can’t choose between them. What chooses is a set of forces: things that are true about this integration, this company and this landscape, and that push the design one way or another.
There’s no formula that weighs them for you. But there is a list, and Salesforce’s own decision guide is a good place to start it. It groups its questions into six areas: existing tools and landscape; data flow; implementation; maintainability; data volume; and limits (module 2). I teach the same ground as seven forces. Each one is a question you’ve already learned to ask, somewhere in this course.
Seven Forces
Section titled “Seven Forces”| Force | The question | The guide’s area | Where the course teaches it |
|---|---|---|---|
| Coupling | How much should each system know about the other? | Data flow | Chapter 7 module 4, chapter 11 |
| Consistency | When must both sides agree, and what happens in between? | Data flow | Chapter 15 module 3, chapter 14 |
| Scale | How many, how big, how often, and in three years? | Data volume | Chapter 6 module 3 |
| Latency | Does someone wait, and how old may the data be? | Data flow | Chapter 6 module 2 |
| Security | Who is calling, and what does the data need on the way? | Existing tools and landscape | Chapter 13 |
| Team skills | Who builds it, and who runs it after the project? | Implementation, maintainability | Chapter 6 module 6 |
| Running cost | What does it count against, every day? | Limits, maintainability | Chapter 6 module 6, chapter 11 module 5, module 5 |
Here’s what each one pulls on.
Coupling. In class I put it this way: with events, “process one doesn’t need to know anything about process three and four… they never have to coordinate. It’s loose coupling of systems.” The guide asks it directly: “How tightly-coupled should systems be?” A direct callout couples Salesforce to the other system’s address, its credential, its outages. An event or an integration layer in between loosens that, at the price of one more thing to run.
Consistency. Some data has to agree on both sides before anyone acts on it; some can catch up. There’s no rollback across systems (chapter 15 module 3), so the question is how long “in between” may last, and who sees it. The guide asks the same thing from the failure side: “What are the needs around exception handling (retry, notify, fail)?”
Scale. “When nobody will give you a number, ask for the number of zeros.” Then turn it into transactions and bytes per second, in the busiest window, three years out. Scale is the force that most often moves an integration from one mechanism to another: from one call per record to sets, from sets to the Bulk API.
Latency. “There’s a big difference between under a second and one to five minutes.” Ask whether someone waits for the answer. If not, near real time is usually cheaper and simpler than real time, and it’s usually what the business meant.
Security. One integration, one identity; the data protected on the way; the door each system offers (chapter 13). Security rarely picks between two mechanisms on its own, but it can rule one out: a mechanism that can’t use the authentication you need isn’t an option.
Team skills. The guide asks: “What teams will be expected to maintain the integration? What skills do they currently have?” Clicks or code, the Salesforce team or the integration team. The best design is one the team can keep running after the project ends.
Running cost. Not just licences. API calls against the daily allocation, event deliveries against theirs, storage, the integration layer’s capacity, and people’s time when something fails. The guide calls it “the total cost of ownership over time.” Module 5 does the licence part properly.
Forces Pull Against Each Other
Section titled “Forces Pull Against Each Other”If the forces all pointed the same way, nobody would need an architect. They usually don’t.
Take Steve Trucking’s truck positions. FleetLink sends Salesforce each truck’s latest position: about 200,000 readings a day. Checkpoint 1 named the pattern, Remote Call-In (chapter 7 module 7). Now two forces pull.
The requirement says how far each force may go.
Latency pulls towards one call per reading: every position, the moment it happens. That’s 200,000 calls a day, all counted against Salesforce’s daily API allocation.
Running cost and scale pull the other way: one call a minute with every truck’s latest position. That’s 720 calls over a twelve-hour day, and the positions are up to a minute old.
Neither force wins on its own. The requirement settles it: coordinators must be alerted within five minutes when a truck is likely to miss its window. A position a minute old is well inside that. So the cheaper design meets the requirement, and the faster one buys nothing the business asked for.
That’s the habit. When two forces pull against each other, go back to the requirement and ask how far each one actually needs to go. Most of the time the requirement has the answer. When it doesn’t, you have a real trade-off, and module 4 shows how to weigh one and say it out loud.
Test knowledge. Expect scenarios where two designs both work, and the details decide: the volume, how fresh the data must be, whether a user waits, which team maintains it, the licences or allocations involved. Name the force each detail is about, then choose the mechanism that meets the requirement without paying for more than it asks.
Beyond the exam: what AI changes. An AI assistant can list the forces faster than any of us, and it’s a good way to check you haven’t forgotten one. What it can’t tell you is which ones matter here: that this team has never run an integration layer, or that finance closes on the third working day. Give it those facts, and ask it where the forces pull against each other. Then check its answer against the requirement, the way the truck positions were settled.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- For each arrow: the forces that matter, and the ones that don’t.
- Where two forces pull against each other, and what the requirement says about how far each may go.
- What’s left over: the real trade-offs, for module 4.
Explore
Section titled “Explore”- Salesforce Architects, Data Integration with Salesforce (opens in a new tab): the six areas to consider (checked 2026-11-07).
- Understanding Integration Requirements: chapter 6, where most of these forces begin.