The question this module answers: What do “call-out” and “call-in” mean, and why does it matter which one an integration is?
Before the patterns, two more words, because Salesforce’s patterns are named with them. One of the six is even called Remote Call-In.
We’re a Salesforce-centric world in this course. I like to make all my Salesforce boxes blue, and everything else another color, and then the words follow from where Salesforce sits.
If Salesforce makes the call, that’s a call-out. The traffic is outbound.
If another system calls Salesforce, that’s a call-in. The traffic is inbound. In Salesforce’s words, the Remote Call-In pattern is data in Salesforce being “created, retrieved, updated, or deleted by a remote system” (Integration Patterns (opens in a new tab), Salesforce Architects, checked 2026-11-01).
So it’s all relative. From the other system’s side, the same call is its call-out. These are Salesforce-centric words, and you just want to watch the words you’re using. But with Salesforce at the center, a call-out is outbound and a call-in is inbound, and that’s how the exam uses them.
Here’s the part people miss. A call-in isn’t only a partner or a vendor’s system. It’s any external client, and that can easily be your own middleware.
The question is the one from chapter 5: who opens the connection? On a landscape, that’s where the arrow starts. So let’s read Steve Trucking’s landscape, every box in the place it had in chapter 5: first all of it, then only the call-ins, then only the call-outs.
Two arrows come into Salesforce. FleetLink calls in with the latest truck positions. And look where the partners’ manifests come from. Redrock, Keystone and Brightwave don’t call Salesforce at all. They send their manifests to the integration layer, and the integration layer calls in, with the partner key. Our own middleware is the external client.
Four arrows go out, and Salesforce starts every one: the status events and the delivery counts to the integration layer, the photos to storage, and the day-before message to the provider. Notice the integration layer again. It’s on both pictures. It calls in with the manifests, and Salesforce calls out to it with the status events. The same system can be on both ends; each arrow has its own starter, its own credential and its own word.
A call-out is Salesforce acting as the client. You’ve already built them: the named credential holds the address and the secret, and Flow, External Services or Apex makes the call. Its limits are counted per transaction, and chapter 9 gives them.
A call-in is another system acting as the client, against Salesforce’s APIs. It signs in through an External Client App, as its own integration user: Salesforce’s guide sends even the old SOAP login() call there, to “OAuth2.0 using External Client Apps”. And every call-in spends from the org’s daily allocation of inbound calls, the one every caller shares (chapter 6). Chapter 8 is Salesforce as the provider, and chapter 12 is how callers sign in.
So when someone says “it’s an integration with Redrock”, ask the next question: which way is the call? The answer sends you to a different set of tools, a different credential and a different limit.
For every arrow: whether it’s a call-out or a call-in, from who opens the connection, not which way the data goes.
For every call-out: the named credential, and the mechanism that makes the call.
For every call-in: the integration user and the External Client App it signs in with, and its share of the daily allocation, including your own middleware.
Beyond the exam: what AI changes. An agent can be either. When Salesforce’s own agent calls another system, that’s a call-out, through the same named credentials. When someone else’s agent calls Salesforce, that’s a call-in, and it needs its own integration user, its own app, and its own estimate against the allocation, because agents can call far more often than people expect. Draw the agent on the landscape, and ask the same question: who opens the connection?
