Leaving Salesforce
Module 1 of 8 in the chapter Salesforce as an API Consumer, chapter 9 of the Integration Architect course. Each module stands on its own. Next: The Six Lines of a Callout
The question this module answers: What are all the ways out of Salesforce, and what do you need before anything can leave?
Chapter 8 was every way into Salesforce. Now we flip the script. We’re inside Salesforce, and we’re the ones making the call.
It starts with an action. An opportunity closes, a delivery is marked delivered, somebody presses a button, a scheduled job wakes up at two in the morning. Something happens, and we need to leave Salesforce and go to another server. We might go to tell it something, to ask it something, or to push or pull data. And the limits on reaching out of Salesforce are a whole different set from the limits on reaching in.
Salesforce Won’t Let You Leave Until You Approve It
Section titled “Salesforce Won’t Let You Leave Until You Approve It”Salesforce blocks outbound calls. You cannot leave Salesforce and make an outbound call unless you approve it. That’s a good thing. Code, a flow or an AI agent can’t quietly send your data anywhere it likes.
You approve the way out with a named credential, the gate you met in chapter 4. Every way out, in clicks or in code, goes through the same gate. You’ll still find the older approval, remote site settings, in many orgs; it only holds the address, and chapter 17 (coming soon) tells its history.
Three Things You Need to Reach Another System
Section titled “Three Things You Need to Reach Another System”To reach any other system, you need to know three things.
- The location. Where is it? Its address: the URL, the port.
- The credentials. How do I prove who I am? A token, a key, a certificate.
- The functions. How do I talk to it? Is it REST, or SOAP? Which verbs, which addresses, what do I send and what comes back?
A remote site setting only gave you the first. A named credential gives you the first two: the location and the way to sign in. The third is yours. It’s the contract from chapter 3, and the rest of this chapter is about calling it well.
The Map of the Ways Out
Section titled “The Map of the Ways Out”When I teach this, I put up a road map of leaving Salesforce: every way out on one page. It’s the mirror of chapter 8’s map of the ways in, and it’s built the same way. Each set is named for what Salesforce is doing, and every way out says where in the course it’s taught.
The ways out of Salesforce, in sets. Blue is this chapter.
Read the sets as different ideas, not just different tools:
- Calls out, in code or in clicks: Salesforce starts the conversation and reaches the other system directly. This chapter is mostly about these.
- Publishes; others subscribe: Salesforce doesn’t call anyone. It puts an event on the bus, and whoever cares comes and gets it (chapter 11).
- Pushes the old way: outbound messages, Salesforce’s own queue that delivers to a listener you build. It’s an old car that’s still running, and module 7 covers it.
- Shows outside data without copying it: Salesforce Connect reads the data where it lives (chapter 19 (coming soon)).
- Agents call out: an agent’s actions are flows, Apex or External Services, and Agentforce can now call outside tools as an MCP client (chapter 22 (coming soon)).
- Connects Salesforce’s own products: the connectors to Salesforce’s other clouds, built for you.
Choosing a Way Out
Section titled “Choosing a Way Out”The same news can leave Salesforce in more than one way. Take Steve Trucking’s delivery status. In chapter 4, a few lines of Apex told Redrock directly that a delivery was made: calls out, in code. In Checkpoint 1, the design changed: Salesforce publishes one status event, and the integration layer delivers it to every partner in the way each one wants: publishes, and others subscribe. Same news, two sets on the map.
So how do you choose? When I walk through the options for telling another system that a record changed, I come back to three questions:
- What can the other system do? Can it subscribe to Salesforce’s events, or does it only expose a web service you have to call? If it only takes calls, you’re calling out.
- Is there something in the middle? If you have an integration layer, it can play any of these parts: subscribe to the events, expose an address, make the call. Then Salesforce often only needs to publish.
- Where should the logic live, and who will look after it? Clicks are simpler, but they may not handle complicated mapping or intricate steps. Code has more complexity, but it can handle more. Choose by the skills of the team that will own it, not only the team that builds it.
Watch it on video
Section titled “Watch it on video”In early 2024 I made a video on eight ways to tell another system that a record changed, in configuration and in code, and how to choose between them. The note under the video says what’s still right and what’s changed since.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- The set, before the tool. For each arrow leaving Salesforce: does Salesforce call, publish, push, show, or let an agent call? The pattern from chapter 7 usually answers this.
- The three things, written down. The location, the credentials and the functions for every system you call, before anyone builds.
- The gate. Every way out through a named credential; any remote site setting you find, on a list to replace.
- Clicks or code. By what the other system can do, what’s in the middle, and who will own the logic.
Explore
Section titled “Explore”- Every Way Out, One Gate: chapter 4, the named and external credential
- All the Locked Doors: chapter 8, the map of the ways in
- Named Credentials: Get Started (opens in a new tab): Salesforce Developers (checked 2026-11-07)