The Admin's Integration Toolkit

Chapter 4 of Integration Architect, Part 1: Understanding Integration (See). Previous: APIs, Contracts and Data Across the Wire · Next: Understanding the System Landscape.

In chapter 3, we opened the call up: the request, the contract, the data on the wire. This chapter puts it to work inside Salesforce, with no code. An admin can build a real integration today: register another system’s API from its contract, call it from a flow, keep the secret where nobody can read it, let another system call in, and tell other systems that something happened.

And when it breaks, the admin is often the first one to see it. So the chapter ends there.

The modules follow one example: Steve Trucking’s org working with Redrock, a Retail Partner with its own REST API. Salesforce calls out to Redrock, Redrock calls in, and both sides need to know when a delivery changes.

The ideas in this chapter

• Every call out goes through a gate. The named credential holds where the call goes; the external credential holds how it signs in; a permission set decides who may use it. Two parts of a whole. Dial it in once, and every flow, every Apex class and every agent goes out the same way, with no secret in sight.
• The secret is the spec. Give External Services another system’s OpenAPI file, and its operations become actions you can drop into a flow. External Services is a clean wrapper: it can do only what the spec describes, and it adds no logic of its own.
• No spec? Use a sample. A Flow HTTP callout builds the shape from one sample answer. One sample can’t tell you everything: the field that’s sometimes empty, the list that’s sometimes long, the error it never showed you. Plan for the answer you didn’t see.
• Every call in comes through an app, as a user. The External Client App decides what kind of access a program can ask for; the integration user decides what data it can touch. Both have to say yes. Stay on the minimal scope necessary: a scope you didn’t grant is a door that isn’t there.
• An event says it happened, and doesn’t wait. A flow publishes a platform event, and any number of listeners pick it up, inside the org or outside it. The publisher doesn’t know who’s listening, so write it down. Send the whole package or just the ID; each choice has a cost.
• When it breaks, read the status first. Always, always check the status code: it tells you whose problem it is. A fault path decides what still gets saved. Some errors are worth trying again, after a wait; most aren’t. And some failures make no noise at all: the token that went quiet, the flow that never ran.

The path through this chapter

Six modules, each standing on its own.

1. Named and External Credentials. The gatekeeper out; the problem they solve; two parts of a whole; every way out, one gate; the ways to sign in to the other system; and what they replace.
2. External Services From an OpenAPI Spec. The secret is the spec; register it; use the actions in a flow, in Apex and in an agent; and what happens when the spec changes.
3. Flow HTTP Callouts. What you still need; build one from a sample; what one sample can’t tell you; plan for the answer; and how to choose between a spec and a sample.
4. Who’s Calling In. The gatekeeper in; how much power the gateway has; settings and policies; server to server with the client credentials flow; and the user it runs as.
5. Platform Events in Flow. Define the event; publish it from a flow; one event, many listeners; how the listening flow runs; and what goes in the event.
6. What You’ll See When It Breaks. Read the status first; a fault path changes what’s saved; uncommitted work pending; the token that went quiet; the flow that never ran; and where to look first.

The toolkit is where many integrations start, not where they all end. Chapter 8 is every door into Salesforce, chapter 9 is Salesforce calling out with Apex, events at depth are chapter 11, signing in is chapter 12, and testing, retries and recovery are chapter 13. When a call has outgrown Flow, those chapters are where it goes.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

• For every system Salesforce calls, one named credential, how it signs in, who may use it, and who owns the secret in each org.
• Spec or sample, for every call from a flow, and who checked the shape Flow built.
• For every system that calls in, its own External Client App and its own integration user, with the smallest scopes and the smallest permissions that work.
• Event or call, for each change other systems care about, what goes in the event, and who listens.
• What every fault path does, whether the record is still saved, which errors are tried again and when to stop, and who acts on each error.
• When an integration has outgrown the no-code tools, and moves to Apex or to middleware.

Beyond the exam: Every tool in this chapter now has an AI side. An agent can use the same External Services actions a flow uses, and an AI tool outside Salesforce calls in the same way Redrock does: through an app, as a user. So the same questions apply, and they matter more: which gate, which user, what can it touch, and what happens when it fails? Each module ends with what AI changes. Chapter 21 goes further.

Explore

• Salesforce Developers, Named Credentials: Get Started (opens in a new tab).
• Salesforce Help, External Client Apps (opens in a new tab).
• SteveTechArc, HTTP Status Codes: every standard code, whose it is to fix, and whether to try again.
• Each module’s Explore section has the Salesforce pages behind it, with the date each was checked.

Next: Understanding the System Landscape