Skip to content
SteveTechArcSteveTechArc Courses

One Integration, One Identity

Module 4 of 8 in the chapter Trust, Identity, and Integration Security, chapter 13 of the Integration Architect course. Each module stands on its own. Previous: The Three Doors · Next: Choosing a Flow

The question this module answers: Who should an integration be when it signs in, and how little should that identity be able to do?

The Saturday Lockout

Section titled “The Saturday Lockout”

Let me tell you about a Saturday.

This was a real project. Salesforce, MuleSoft, and the REST API, synchronizing data. One MuleSoft integration, call it A, had been running in production for months, signing in as the integration user once or twice a second. All good.

Then another team brought up a second MuleSoft component, B. They shared the integration user. And they got the password wrong. B sent in a handful of requests with the wrong password. Who’s locked out now? Both of them.

So you shut off B. Easy, the team’s right there. But A is still running like clockwork, signing in twice a second, against a locked account. You go to the user screen and reset the password, and it locks out again a split second later. Why? Because A is still trying to connect, multiple times a second, with the old password. Every reset is locked again before anyone can use it.

One user, two integrations, one Saturday One user, two integrations, one Saturday. Integration A, in production, signs in once or twice a second with the right password, as one shared integration user, highlighted, into Salesforce. Integration B, new, signs in as the same user with the wrong password, marked as failed. The shared user is locked after too many wrong passwords, and both integrations are locked out of Salesforce, marked as failed. The legend: the shared user means one team's mistake stops both. Underneath: every reset was locked again within a second, because A kept signing in; one integration, one user. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-INT-TW-06", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} Integration A in production, signing in once or twice a second Integration B new, with the wrong password One shared integration user locked after too many wrong passwords Salesforce both integrations stopped the right password the wrong password locked out Every reset was locked again within a second, because A kept signing in. One integration, one user. HOW TO READ IT The shared user: one team's mistake stops both © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

One shared user: one team’s mistake stopped both integrations.

And it was a Saturday. Team A was off. We had to find someone from team A to turn their integration off. And then we couldn’t simply give them a new password: theirs was encrypted in a key store. So to get back to the old password, I changed the user’s profile so it didn’t remember old passwords, and changed the password ten times, because it remembered the last ten, until I could set the old one back. Then team A turned their integration back on.

The safety tips I gave the class: be careful with a shared password, don’t make an integration user’s password expire, and think about whether old passwords can come back. But the real lesson is simpler. Don’t share. Different integration users for different integrations.

The Same Failure, With Tokens

Section titled “The Same Failure, With Tokens”

That story happened with a password, and I tell it that way because that’s how it happened. Integrations today sign in with tokens, so does the lesson still hold? It does, and Salesforce’s own documentation shows how.

With refresh token rotation on (module 1), each refresh token works once. Salesforce: “any attempted reuse of an invalidated refresh token results in the immediate revocation of the current refresh token and all associated access tokens, requiring the client to re-authenticate via a new flow” (Enforce One-Time-Use Refresh Tokens with Refresh Token Rotation (RTR) in Salesforce (opens in a new tab), Salesforce Help, October 21, 2026, checked 2026-11-07). That’s the right behavior: it’s how a stolen token gets caught.

Now picture two integrations sharing one refresh token. The first refreshes and gets a new one. The second presents the old one. To Salesforce, that looks exactly like a stolen token being reused, and it cuts off both. Same Saturday, different mechanism. Shared identities break each other, whatever they sign in with.

Salesforce Says It Too

Section titled “Salesforce Says It Too”

This isn’t just my preference. Salesforce’s own guidance, in its words: “Following the principle of least privilege, we recommend creating and configuring one Salesforce user for every integration.” A different user for each calling system, domain, use case or API resource keeps each one to its own slice of data and functionality. And the reason: it “gives you more control over operations and traceability of transactions. And it minimizes the impact if a user or integration is compromised” (Give Integration Users API Only Access (opens in a new tab), Salesforce Help, checked 2026-11-07).

Three wins, then:

  • Failures stay put. A locked, expired or misconfigured identity stops one integration, not all of them.
  • Theft stays small. If one integration’s credentials are stolen through the partner door, the thief gets that integration’s data, not everything every integration can touch.
  • Every record says who did it. Created By and Last Modified By name the integration, so when something odd appears, you know which arrow to look at.

Steve Trucking’s Identities

Section titled “Steve Trucking’s Identities”

Notice the words “calling system, domain, use case, or API resource.” That’s finer than one user per system. At Steve Trucking, the integration layer does two very different jobs, so it gets two identities:

Steve Trucking's integration identities Steve Trucking's integration identities, four rows, each caller signing in as its own user. The integration layer, for partner manifests in, signs in as the manifests user, which creates and updates Work Orders by the partner key. The integration layer, for status events out, signs in as the status user, which reads Work Orders and subscribes to Delivery Update. FleetLink, for truck positions, signs in as the positions user, which updates each truck's last position and nothing else. The bulk loading tool, for nightly files and loads, signs in as the loads user, with only the objects in the load, turned off between runs. Underneath: each user has its own External Client App, API only, and one permission set; if one is locked, stolen or retired, the other three keep working. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-INT-TW-07", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} The integration layer partner manifests in The integration layer status events out FleetLink truck positions The bulk loading tool nightly files and loads Manifests user creates and updates Work Orders by the partner key Status user reads Work Orders; subscribes to Delivery Update Positions user updates each truck's last position, nothing else Loads user only the objects in the load; off between runs signs in as signs in as signs in as signs in as Each user: its own External Client App, API only, one permission set. If one is locked, stolen or retired, the other three keep working. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Four jobs, four identities.

  • Manifests in. Creates and updates Work Orders by the partner key. It never reads anything else.
  • Status out. Reads Work Orders and subscribes to Delivery Update (chapter 11). It never writes.
  • Truck positions. FleetLink updates each truck’s last position, and nothing else.
  • Bulk loads. Only the objects in the load, and turned off between runs.

If FleetLink’s credentials leak, the thief can move a truck on a map. They can’t read a single delivery.

Five Gates

Section titled “Five Gates”

One identity per integration is the start. Then you make each identity as small as its job. I think of it as five gates, each narrowing what the identity can do.

Five gates on one integration user Five gates on one integration user, numbered down a line, with what each limits beside it. 1, the license, Salesforce Integration, API only: no screens, it can't sign in to the user interface at all. 2, the permission set, only its objects and fields: what the user can see and change, and nothing more. 3, the app's scopes, only the APIs it calls: the api scope, not full, and refresh only if it needs it. 4, where it comes from, IP ranges or a client certificate: only from the partner's addresses, or proven by two-way TLS. 5, highlighted, which apps may call, installed apps and API Access Control: only approved apps reach the API at all. Underneath: each gate assumes the one before it might fail. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-INT-TW-08", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "flow/sequence 0.1.0", "theme": "stevetecharc 1.4.0"} The license Salesforce Integration: API only No screens: it can't sign in to the user interface at all. The permission set only its objects and fields What the user can see and change, and nothing more. The app's scopes only the APIs it calls The api scope, not full; refresh only if it needs it. Where it comes from IP ranges, or a client certificate Only from the partner's addresses, or proven by two-way TLS. Which apps may call installed apps; API Access Control Only approved apps reach the API at all. 1 2 3 4 5 WHAT IT LIMITS Each gate assumes the one before it might fail. HOW TO READ IT 1 the order a step the step that matters most what comes next © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Each gate assumes the one before it might fail.

  1. The license: API only. The Salesforce Integration user license comes with the Minimum Access - API Only Integrations profile, and “You can’t turn off the API-only access granted through this profile.” The user can’t sign in to the screens at all. It’s in Enterprise, Unlimited, Performance and Developer Editions (same page, checked 2026-11-07).
  2. The permission set: only its objects and fields. The profile starts with almost nothing. Add exactly what the job needs, in a permission set named for the integration, so anyone can see what it can do.
  3. The app’s scopes: only the APIs it calls. The api scope, not full; refresh_token only if it really runs unattended (chapter 4).
  4. Where it comes from. Lock it to the partner’s IP addresses where you can. Where addresses change, as on Hyperforce, prove the machine with a client certificate instead (chapter 12).
  5. Which apps may call at all. Uninstalled apps are already blocked for ordinary users (module 3). Go further with API Access Control, which can “restrict all users from accessing your Salesforce APIs unless they’re pre-authorized through an approved (allowlisted) connected app.” You request it from Salesforce Support (Manage API Access (opens in a new tab), Salesforce Help, checked 2026-11-07).

Why five? Because each gate assumes the one before it might fail. The password leaks: the IP lock stops it. The IP lock is too wide: the permission set limits what it reaches. That’s defense in depth, for one identity.

Keep the Identities Alive and Honest

Section titled “Keep the Identities Alive and Honest”

Identities need looking after, like the arrows they belong to:

  • Name them for the job, and record the owner, the app and the permission set in the landscape inventory (chapter 5).
  • Turn them off when the integration retires. A forgotten identity from an old test integration is exactly what an attacker hopes to find.
  • Don’t let them expire by surprise. A password or a certificate that lapses on a Saturday is the same Saturday again.
  • Watch them. Each identity has a normal: how often it calls, what it reads, from where. A change from normal is the first sign of trouble (chapter 14).

Test knowledge. One integration user per integration (Salesforce: “one Salesforce user for every integration… each calling system, domain, use case, or API resource”). The Salesforce Integration user license and the Minimum Access - API Only Integrations profile give API-only access; add permissions through permission sets (the Salesforce API Integration permission set license extends it). Narrow OAuth scopes, IP restrictions, and API Access Control (requested from Support) to allowlist approved apps. Shared identities fail together: a lockout or a reused rotated refresh token cuts off every integration that shares it.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • The identity map: one identity per integration, and per job where an integration does several, named and owned.
  • For each identity, the five gates: the license, the permission set, the scopes, where it may come from, and which apps may call.
  • What each identity may never do, written down, so a review can check it.
  • How each identity is retired, and what happens to its records and tokens when it is.
  • What normal looks like for each, so the unusual call stands out.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.