Who's Calling In

Module 4 of 6 in the chapter The Admin’s Integration Toolkit, chapter 4 of the Integration Architect course. Each module stands on its own. Previous: Flow HTTP Callouts · Next: Platform Events in Flow

The question this module answers: When another system calls into Salesforce, what decides what it’s allowed to do?

The first three modules were Salesforce calling out. Now turn around. Redrock’s system wants to call into Steve Trucking’s org: to read a delivery, to update its status. Salesforce is the server now, and it has the same job any server has. Who is this, and what are they allowed to do?

Anything that’s connecting in to the org comes through a gateway. In You’re Already Doing Integration we met it by its new name: the External Client App. For years it was the connected app, and you’ll still find those in older orgs. This module sets one up, and the user behind it.

The Gatekeeper In

Going out, the gate was the named credential and the external credential: two parts of a whole. Coming in, it’s two parts again. As I put it in class: we have the user account and the app, and they each regulate different levels of security.

The External Client App is which program is calling, and how it signs in. It holds the program’s client ID and secret, and its scopes: what kind of access the program can ask for at all.

The integration user is who the program runs as. Its profile and permission sets decide which objects, fields and records it can actually touch, the same way they would for a person.

Both have to say yes. The app’s scope can allow the APIs, and the user can still have no access to the delivery object. The user can see deliveries, and the app’s scope can still keep the program out of the APIs. What the program can do is only what both allow.

Click to enlarge

The gatekeeper in: the app and the user.

Decide How Much Power the Gateway Has

The app is like a gateway into the org, and you get to decide how much power that gateway has. That’s what scopes are for.

Salesforce has a list of them. The one most integrations need is api: in Salesforce’s words, it “Allows access to the current, logged-in user’s account by using APIs, such as REST API and Bulk API 2.0” (OAuth Tokens and Scopes (opens in a new tab), Salesforce Help, checked 2026-11-01). There’s also full, which is everything the user can reach, and refresh_token, which lets the program keep working while nobody’s there.

Stay on the minimal scope necessary. If Redrock only calls the REST API, give its app the api scope and nothing else. A scope you didn’t grant is a door that isn’t there.

And give each integration its own app. You can have many gateways into the same org: one for the bulk loading tool, one for Redrock, one for the warehouse system, each with its own scopes and its own client ID and secret. Then when one has to be shut, the others keep working.

Settings and Policies

An External Client App has two sides, and they belong to two different people (External Client Apps (opens in a new tab), checked 2026-11-01):

• The settings belong to whoever builds the app: its OAuth settings, its callback address, its scopes. They can be packaged and installed in other orgs.
• The policies belong to the admin of each org: who’s allowed to use the app, which IP addresses it can come from, how long its sessions last. In Salesforce’s words, “These unique policies are never packaged, and only affect the admin’s local org.”

So when a vendor’s app arrives in your org inside a package, its settings come with it, and its policies are still yours to set. That’s the admin’s half of the gate.

The secret is kept apart too. The OAuth settings with the secret in them “can never be packaged.” And watch this one when you refresh a sandbox: “Local external client apps aren’t copied to a new sandbox when you clone or refresh a sandbox.” It’s the same lesson as the named credential in module 1: the secret doesn’t travel. Plan to set up the app again in each sandbox, with its own secret.

Server to Server

Most integrations have no person in them. Redrock’s system calls at two in the morning; nobody is there to sign in. For that, Salesforce has the client credentials flow: the program trades its client ID and secret for a token. In Salesforce’s words, the flow “eliminates the need for explicit user interaction, though it does require you to specify an integration user to run the integration” (OAuth 2.0 Client Credentials Flow for Server-to-Server Integration (opens in a new tab), checked 2026-11-01).

So the user is still there. You choose it in the app’s policies, and every token the app gets is a token for that user:

1. Redrock’s system sends the app’s client ID and secret to Steve Trucking’s token address, its My Domain.
2. Salesforce checks them.
3. Salesforce returns an access token “on behalf of the integration user you assigned.”
4. Redrock’s system calls the API with the token.
5. The API answers, with only what that user can see.

Click to enlarge

No person signs in, but every call runs as a user.

That makes the client ID and secret the keys to the integration user. Salesforce says it plainly: “any person or app that has access to your external client app’s consumer key and consumer secret can get an access token.” So keep them secure, in the other system’s own secret store, never in an email or a chat. Change the secret on a schedule, and change it at once if it might have leaked.

The User It Runs As

The user deserves the same care as the app. The front-door chapter tells the story of one shared integration user, locked out by a second team’s wrong password, taking both integrations down with it. Its lessons apply here:

• One integration, one user. Redrock gets its own integration user, so a mistake or a compromise stays with Redrock.
• API only. Salesforce gives Enterprise, Performance, Unlimited and Developer Edition orgs Salesforce Integration user licenses, with a profile that allows API access only. A user that can’t sign in to the screens is one less door.
• Only the access its job needs. A permission set with the objects and fields Redrock works with, and nothing else.

What an Architect Decides Here

• For every system that calls in, its own External Client App and its own integration user.
• The smallest scopes that work, and the smallest permissions behind them.
• Who sets the policies on each app, including the ones that arrive in packages.
• Where each app’s client ID and secret are kept, who can see them, and how often the secret changes.
• How each app gets set up again after a sandbox refresh.
• Which connected apps are still in use, and when they move to External Client Apps.

Beyond the exam: what AI changes. AI tools and agents outside Salesforce come in the same way: through an app, as a user. That’s the question to ask of every one: which app, which user, and what can that user touch? An agent with a broad scope and an admin’s permissions is a fast way to lose a lot of data. Give it the same treatment as Redrock: its own app, its own user, the smallest power that works. Chapter 21 goes further.

Explore

• Salesforce Help, External Client Apps (opens in a new tab), checked 2026-11-01.
• Salesforce Help, OAuth 2.0 Client Credentials Flow for Server-to-Server Integration (opens in a new tab) and OAuth Tokens and Scopes (opens in a new tab), checked 2026-11-01.
• You’re Already Doing Integration: the connected app’s new name, and why the approve button is an integration decision.
• Chapter 12 goes deeper on signing in: every OAuth flow, and the protections around them.