Study guide

Study guide for chapter 4 of the Integration Architect course. Read the six modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries one exam objective, choosing an option for outbound calls, from the Build Solution section (23% of the exam). It’s the no-code half: named and external credentials, External Services, Flow HTTP callouts, the gate coming in, and platform events in Flow. It also supports security for inbound and outbound integrations (BLD-5) and error handling (BLD-4, MNT-2). The exam guide aligns to Summer ‘23, so some of what’s here is newer than the exam, and dated.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

The gate out: named and external credentials (BLD-2, supports BLD-5)

• I can say it in one line: the endpoint and authentication live in the named credential; the protocol lives in the OpenAPI spec. (Named and External Credentials)
• I know the gate answers three questions: is it allowed to go there, who is leaving, and how does it get in on the other side. (The Gatekeeper Out)
• I know the named credential is where (the address) and the external credential is how (the protocol and the encrypted secrets), and that one external credential can serve several named credentials. (Two Parts of a Whole)
• I know the external credential’s principals are given to users through permission sets, so only the people you allow can leave. (Two Parts of a Whole)
• I know Apex calls callout: and the named credential’s name, with no address or secret in the code. (Every Way Out, One Gate)
• I know the ways to sign in to the other system: no authentication, Basic, Custom (an API key in a header), OAuth 2.0, JWT and AWS Signature Version 4, and that OAuth client credentials is usually the choice. (The Ways to Sign In to the External System)
• I know named principal (one identity for everyone) from per user (each user as themselves). (The Ways to Sign In to the External System)
• I know the secrets don’t deploy from sandbox to production; they’re entered in each org. (Dial It In Once)
• I know legacy named credentials are deprecated, and a callout to a named credential needs no remote site setting. (What They Replace)

External Services (BLD-2)

• I know External Services needs the API’s OpenAPI file, version 2.0 or 3.0, with a plain server address. (The Secret Is the Spec)
• I can register one: get the spec, create the named credential, register the service, choose the operations, use them in a flow. (Register the Spec)
• I know each operation becomes an action in Flow, Apex, Orchestrator, OmniStudio and Agentforce, and the wrapper adds no logic of its own. (Use the Actions)
• I know which schema updates Salesforce allows: adding is safe, some removals are allowed but can break things, some aren’t allowed while in use, and a rename counts as a delete and an add. (When the Spec Changes)

Flow HTTP callouts (BLD-2, supports BLD-4)

• I know the HTTP callout builds the shape from a sample instead of a spec, and creates an external service behind the scenes. (Build One)
• I know what one sample can’t tell Flow: allowed values (no enums), some number types, mixed-type lists, request headers, more than 15 levels deep. (What One Sample Can’t Tell You)
• I know a status of 300 or greater goes down the fault path, and every callout action needs one. (Plan for the Answer)
• I know a record-triggered flow calls out on an asynchronous path. (Plan for the Answer)
• I can choose: External Services when there’s a spec, the HTTP callout for a quick call without one, and Apex when it’s complicated. (Spec or Sample?)

The gate in (supports BLD-5)

• I know two parts have to say yes: the External Client App (which program, and its scopes) and the integration user (which objects, fields and records). (The Gatekeeper In)
• I give each integration its own app with the minimal scopes, usually api. (Decide How Much Power the Gateway Has)
• I know an External Client App’s settings belong to its builder and can be packaged, while its policies belong to each org’s admin, and that local apps aren’t copied to a refreshed sandbox. (Settings and Policies)
• I know the client credentials flow trades a client ID and secret for a token on behalf of the integration user you assign. (Server to Server)
• I know the integration user rules: one integration, one user; API only, with the Salesforce Integration license; only the access its job needs. (The User It Runs As)

Platform events in Flow (BLD-2)

• I know a platform event (API name ending in __e) takes only checkbox, date, date/time, number, text and long text fields, so it survives outside Salesforce. (Define the Event)
• I know a flow publishes with Create Records, and that Publish Immediately (the default) can go out before the save, while Publish After Commit waits for it. (Publish It From a Flow)
• I know listeners can be a platform event–triggered flow, a paused flow, or an outside system through the Pub/Sub API, which connects in to receive. (One Event, Many Listeners)
• I know a listening flow runs later in its own transaction, in batches of up to 200, as the publisher, with no order between listeners, and sends no email if it never starts. (How the Listening Flow Runs)
• I can choose what goes in the event: the whole package, or just the ID for the listener to call back for. (What Goes in the Event)

When it breaks (supports BLD-4 and MNT-2)

• I can read the status to find the gate: 401 and 403 the sign-in or the access, 400 and 404 the request, 500s and 503 the other side, 429 slow down. (Read the Status First)
• I know which errors to try again: a 429 after the wait it asks for, the 500s with a growing wait, and the other 400s never: fix the request. (Read the Status First)
• I know that with no fault path the save rolls back, and with one the record is saved. (A Fault Path Changes What’s Saved)
• I know you can’t write and then call out in one transaction, and how the asynchronous path and Let the flow decide (Winter ‘26) help. (Uncommitted Work Pending)
• I know an idle refresh token expires after 30 days unused in External Client Apps, and that client credentials has no refresh token to go quiet. (The Token That Went Quiet)
• I know where to look first: the status and fault message, replicate it, debug logs on a second user, then the failed interviews and error emails. (Where to Look First)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

• Everything that leaves goes through the same gate, clicks or code.
• When AI writes a callout, check where it put the address and the secret.
• Dial it in once, and write it down, for the person on call at two in the morning.
• Register only the operations you need, and keep a list of what uses each external service.
• Stay on the minimal scope necessary. A scope you didn’t grant is a door that isn’t there.
• The secret doesn’t travel. Plan to set it in each org and each refreshed sandbox.
• Write down who listens to each event. The publisher can’t tell you.
• Check that it happened, not only that nothing failed.
• Debug as a second user, never on a busy integration user, and mask before you look.

Words to Know

Term	In one line
Named credential	Where Salesforce calls: the address, under a name
External credential	How Salesforce signs in to the other system, with the secrets stored encrypted
Principal	The identity Salesforce signs in as on the other system, given to users by permission set
Named principal, per user	One identity for every caller, or each user as themselves
Remote site setting	The old allow list out: an address, open to the whole org
External Services	Salesforce’s way to turn an OpenAPI spec into actions, with no code
HTTP callout (Flow)	A Flow action built from a sample payload instead of a spec
Fault path	The branch a flow takes when an element fails
External Client App	The gateway an outside program comes in through, with its scopes
Scope	What kind of access a program can ask for at all, such as api
Client credentials flow	Server to server: a client ID and secret traded for a token, as the integration user
Platform event	A message published once, for any number of listeners; API name ends in __e
Publish After Commit	Publish the event only once the record is saved
Refresh token	Lets a program keep signing in while nobody’s there; expires if idle too long

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. An org calls out to five systems with remote site settings and the passwords stored in custom settings. What would you recommend?

A named credential for each system, with external credentials holding the secrets encrypted, principals given by permission set so only the right users can leave, and OAuth client credentials where the other side supports it. A remote site setting is only an allow list, open to everyone. Reread What They Replace.

2. A partner publishes an OpenAPI 3.1 file for its API, and the admin wants to call it from a flow with External Services. What do you check?

External Services reads OpenAPI 2.0 and 3.0, not the newer versions, and needs a plain server address. Convert or draft a 3.0 file, check it, and register only the operations you need. Reread The Secret Is the Spec.

3. The partner renames a field in its spec, and you register the new version. Why might flows break?

A rename counts as deleting the field and adding a new one, so anything that used the old name loses it. Keep a list of the flows, Apex and agents using each external service, and agree with the other side how they’ll tell you about changes. Reread When the Spec Changes.

4. A record-triggered flow on the delivery calls the partner's API and fails with "uncommitted work pending." What's the fix?

You can’t write and then call out in the same transaction. Put the callout on the asynchronous path, which runs after the save is committed, and give it a fault path and a log, because the save and the callout now succeed or fail apart. Reread Uncommitted Work Pending.

5. A partner's system calls into Salesforce. Its app has the `api` scope, but every call to read deliveries returns nothing. What would you check?

The integration user. The app decides which program and which APIs; the user decides which objects, fields and records. Both have to say yes. Reread The Gatekeeper In.

6. A listener will call back to read the delivery when it hears the event, and sometimes it reads the old values. Why?

Publish Immediately, the default, can send the event before the record is saved. Choose Publish After Commit when a listener needs the committed data. Reread Publish It From a Flow.

7. A quarterly audit tool that worked in January fails at sign-in in April with `invalid_grant`. Retrying doesn't help. What happened, and what's the better design?

Its refresh token sat unused past the 30-day idle limit and expired. Authorize it again now; for the design, use the client credentials flow, which has no refresh token to go quiet, and watch that each job runs when it should. Reread The Token That Went Quiet.

8. The customer team stopped hearing about late deliveries, and there's no error email anywhere. Where do you look?

At the event’s errors. If an event fails, the listening flow never starts, so no failed interview and no email exist. For anything that matters, check that it happened, not only that nothing failed. Reread The Flow That Never Ran.

Explore

• Salesforce Certified Platform Integration Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam.