コンテンツにスキップ
SteveTechArcSteveTechArc Courses

You're Already Doing Integration

このコンテンツはまだ日本語訳がありません。

Module 2 of 6 in the chapter Think Like an Integration Architect, chapter 1 of the Integration Architect course. Each module stands on its own. Previous: Everything Is Knowable · Next: Every Arrow Is a Decision

The question this module answers: What integration work does a Salesforce admin already do, and how does an integration architect see the same work?

If you’ve ever run Data Loader, you’ve done integration.

That surprises a lot of admins. Integration sounds like something the developers do, with code and middleware and acronyms. But think about what actually happens when you load a file of accounts. A program on your laptop signs in to your org, sends the records across the internet to Salesforce’s APIs, and waits for Salesforce to say which ones saved and which ones failed. That’s two systems talking. Your laptop is the one that starts the conversation, and your org is the one that answers. That’s an integration.

So the first chapters of this course aren’t asking you to learn a new world. They’re asking you to look at things you already do and see them the way an architect does.

The Doors You’ve Already Opened

Section titled “The Doors You’ve Already Opened”

Here’s what most admins already touch, often without calling it integration.

Data Loader and the other load tools. Every load and every export is a call into the org’s APIs from outside it. Data Loader can switch on the Bulk API for big loads: the loading dock out back, which we’ll meet properly in chapter 10.

The integration user. When another system needs to work in your org, it signs in as someone. Hopefully that someone is a dedicated integration user, not a person, and not the admin’s own login. You may have created one, given it a permission set and wondered what to call it. That user is the identity of an integration.

Credentials. If you’ve built a flow that calls out to another system, you’ve met named credentials and external credentials: the place Salesforce keeps the address of the other system and the secret it uses to sign in, so nobody types a password into the flow itself.

The apps you approve. And this is the one that matters most. Every outside tool that connects into your org is registered there. In class I’ve always described that registration as the gateway: anything that’s connecting in to the org comes through it, and you can have many of them, one for each way in. I might have one for a bulk loading tool and give it only the permissions that tool needs. Each one is identified by its own client ID and secret, and each one decides what the tool coming through it is allowed to do.

What an admin already touches One Salesforce org in the middle with five arrows. From the left, an admin with Data Loader loads and exports from a laptop, and a person approves an outside app with one click. From above, the outside app, registered as an External Client App, comes in through the gateway it was given. From the right, another system signs in as the integration user. And Salesforce itself calls out to another system from a flow, with the address and secret kept in a named credential. Underneath: every one of these is an integration; something starts the call, and it signs in as someone. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.48.0", "built": "2026-10-28", "id": "DGM-INT-TL-03", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "system-landscape 0.13.0", "theme": "stevetecharc 1.4.0"} ABOVE: IDENTITY, APPEXCHANGE, WEB PEOPLE RIGHT: INTERNAL SYSTEMS An admin with Data Loader a load from a laptop A person who approves an app one click on Allow An outside app registered as an External Client App Another system signs in as the integration user A system a flow calls address and secret in a named credential Salesforce your org loads and exports approves the app through its gateway as the integration user a flow calls out Salesforce people identity, apps, web an internal system starts at the system that opens the connection; the label says what moves Every one of these is an integration: something starts the call, and it signs in as someone. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Five arrows most admins already own. Each one starts somewhere, and each one signs in as someone.

The Gateway Has a New Name

Section titled “The Gateway Has a New Name”

For years that gateway was the connected app. In class I called it a Swiss army knife, because one connected app could do so many jobs: sign-in, API access, single sign-on.

Today the gateway for anything new is the External Client App. Salesforce has been moving this way for a while, and the dates are now set. Since Spring ‘26, new connected apps can’t be created without a request to Salesforce Support. The ones you already have keep working, and so do the ones that arrive inside installed packages. And a Winter ‘27 release update, enforced in production in Summer ‘27, takes connected apps to end of support. In Salesforce’s words, “Connected apps will keep working, but Salesforce will no longer fix bugs or provide support for the integrations and authorization flows that use them.” Setup offers a Migrate to External Client App action on each one.

So in this course we register every integration as an External Client App. You’ll still find connected apps in older orgs and in managed packages, so you need to recognize them, know they still work, and know where the migration lives. But when you set up something new, you’re setting up an External Client App.

Why the Approve Button Is an Integration Decision

Section titled “Why the Approve Button Is an Integration Decision”

Here’s why I want admins to see all of this as integration, and not as housekeeping.

In 2024 and 2025, attackers called employees at a number of companies, posed as IT support, and talked them into approving an app in Salesforce. The app was usually a modified copy of Data Loader, sometimes renamed to fit the story. Once it was approved, the attackers used it to export data through the API. Google’s threat intelligence team, which tracked the group, put it plainly: “In all observed cases, attackers relied on manipulating end users, not exploiting any vulnerability inherent to Salesforce.” Salesforce called it “a shared responsibility between a provider and their customers.”

Nothing in the platform broke. Someone opened a door, and the integration came through it. That’s the integration architect’s view of an approve button: a new arrow into the org, with an identity, a set of permissions and a volume of data it can move. Salesforce has since closed several of those doors by default (uninstalled apps are restricted, new connected apps are blocked, and the device sign-in flow is limited), and chapter 12 teaches the full set of protections. But the first protection is an admin who knows which arrows exist.

Seeing It Like an Architect

Section titled “Seeing It Like an Architect”

So take the list again: the load tool, the integration user, the credentials, the approved apps. For each one, an architect asks the same short questions we met in Everything Is Knowable: who calls whom, how much, how often, and what happens when it fails. And now two more that you, as an admin, can already answer better than anyone: who is it signed in as, and what is it allowed to do?

If you can answer those for every way into and out of your org, you’re not starting integration architecture. You’re already doing it. The rest of this course gives you the words, the patterns and the depth.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • Which tools, users and apps already connect to the org, written down as a list someone owns.
  • Whether each integration signs in as its own dedicated user: almost always, with a person only where the design calls for it.
  • Which app registration each integration comes through, and whether its permissions are the smallest that work.
  • Which connected apps still need moving to External Client Apps, and by when.
  • Who in the organization is allowed to approve a new app, and who reviews it.

Explore

Section titled “Explore”