Study guide

Study guide for chapter 1 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 is the start of Admins to Architects, so no exam objective belongs to it alone. But it plants the four ideas the rest of the course grows: what an arrow means, the requirements nobody states, change across a boundary, and failure. Each group below says which objectives it supports. The exam guide aligns to Summer ‘23, and the course teaches what’s current, with dates.

For the Exam

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

Everything is knowable (supports LAND-1)

• I start with the whole landscape, then zoom in on one arrow until it’s two systems and one conversation. (Start at 30,000 Feet, Then Land)
• I can ask every arrow the same short questions: who calls whom, how much, how often, and what happens when it fails. (Start at 30,000 Feet, Then Land)
• For every arrow, I know where I log an error, what I tell the user, and how I retry. (Start at 30,000 Feet, Then Land)

What admins already own (supports BLD-5)

• I can see Data Loader as an integration: a program that signs in, calls the org’s APIs and waits for the results. (The Doors You’ve Already Opened)
• I know an integration should sign in as its own dedicated integration user, not as a person or the admin. (The Doors You’ve Already Opened)
• I know named credentials and external credentials hold the other system’s address and secret, so nobody types a password into a flow. (The Doors You’ve Already Opened)
• I know every outside tool comes in through an app registration with its own client ID and secret, and that each one gets only the permissions its tool needs. (The Doors You’ve Already Opened)
• I know the External Client App is the gateway for anything new: since Spring ‘26, new connected apps need a request to Salesforce Support, and a Winter ‘27 release update takes connected apps to end of support. (The Gateway Has a New Name)
• I can explain why approving an app is an integration decision: a new arrow into the org, with an identity, permissions and a volume of data it can move. (Why the Approve Button Is an Integration Decision)

What an arrow means (supports LAND-1)

• I know an arrow can mean who starts the connection or which way the data flows, and that the two can point in opposite directions. (Two Meanings, One Drawing)
• I know the system that starts the call holds the address, the credentials, the schedule and the retry, so getting the initiator wrong puts that work on the wrong side. (Why It Matters Which One You Mean)
• On a system landscape, I start the arrow at the system that opens the connection, let the label say what moves, and say so in the legend. (How I Draw Mine)
• I draw two arrows when one pair of systems has two conversations, such as email-to-case in and replies out. (How I Draw Mine)

The requirements nobody states (supports BIZ-1 and REQ-4)

• I start from what’s already on the ground: which systems stay, which go, and whether Salesforce is already in place. (The Blueprint and the Trades)
• I can tell declared requirements from implied ones, and find the implied ones before go-live. (Declared and Implied)
• I treat error handling as an implied requirement on every arrow: the client won’t ask for it, they’ll assume it. (See the Errors Before They Happen)
• I design for a three-year horizon, with 30% a year as my baseline when the business has no growth number. (A Three-Year Horizon)

Owners, boundaries and change (supports BLD-6)

• I know every arrow crosses a boundary between owners, and that integrations break when one side changes without the other knowing. (Every Arrow Crosses a Boundary)
• I can weigh giving an outside team the standard API against a contract you own, and know the decision belongs in the first weeks of the project. (What Breaks When One Side Changes)
• I know a credential reset or a platform release is change you don’t control, and that someone has to own watching for release and retirement dates. (Change You Don’t Control)

Plan for failure (supports MNT-2)

• I know it’s usually the pathway that goes down, not either system: a provider outage, DNS, a firewall rule, an expired certificate, a patch. (Plan for Failure)
• For every arrow, I can describe normal time and failure time: what happens to the data, how users are told, how it recovers, and how users are told it’s caught up. (Normal Time and Failure Time)
• I can say what happens if an arrow is down for a minute, an hour, a day, or three or four days. (A Minute, an Hour, a Day, a Weekend)
• I know platform events are kept for 72 hours, and that past that window a bulk load, then incremental loads, bring the other system back. (At What Point Is It Data Loss?)

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 is knowable. Keep breaking it down into smaller pieces; every arrow is a Lego building block.
• Give everyone the same words. When I say “fire and forget”, the development team should know exactly what to build.
• Keep a list of every way into the org, with an owner. An admin who knows which arrows exist is the first protection.
• Say what your arrows mean, in the legend, every time.
• Look for the fire exits. If you leave them out, “you didn’t ask” isn’t an answer.
• Decide the boundary on purpose, and early.
• A change nobody told you about is a failure.
• Have the bulk path ready before the long weekend, tested, with an owner. You don’t want to be building it on Tuesday morning.
• Build for today, plan for tomorrow, plan for failure.

Words to Know

Term	In one line
System landscape	Every system in its place and every arrow drawn between them
Client	The system that starts the call
Server	The system that answers it
Integration user	The dedicated user an integration signs in as
Named credential, external credential	Where Salesforce keeps another system’s address and the secret it signs in with
External Client App	The gateway an outside tool comes through to reach the org; the connected app’s successor
Declared requirement	One the client tells you
Implied requirement	One the client expects without saying
Three-year horizon	Designing for the volumes three years out, not only today’s
Boundary	Where an arrow leaves one owner’s system and enters another’s
Normal time, failure time	How an arrow’s traffic flows on an ordinary day, and what happens to it when it stops
Event retention window	How long the event bus keeps an event for a subscriber to catch up: 72 hours for platform events

Check Yourself

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

1. Two people read the same diagram. One says the arrow from the users to Salesforce is wrong, because the data mostly flows from Salesforce to the users. Who's right?

Both, depending on what the arrow means: who starts the connection, or which way the data flows. The users’ browsers start it, and the records come back. The diagram has to say which meaning it uses, in its legend. Reread Two Meanings, One Drawing.

2. An employee gets a call from "IT support" asking them to approve an app in Salesforce. Why is that an integration question?

Approving an app opens a new arrow into the org, with an identity, permissions and a volume of data it can move. Attackers used exactly that in 2024 and 2025, with no platform vulnerability involved. Know which apps exist, who may approve a new one, and who reviews it. Reread Why the Approve Button Is an Integration Decision.

3. The requirement says "send the day's delivery counts to the finance system every night." What would you ask before designing it?

The implied requirements: what happens when finance is down at midnight, what if a run is sent twice, how much it will be in three years, how errors are logged and who’s told. None of them is in the sentence, and every one would be a complaint if it were missing. Reread Declared and Implied.

4. A business makes about 3,300 deliveries a day and has no growth plan. What volume do you design for?

Three years out at 30% a year: about 7,250 a day, more than twice today’s number. Ask the business first; use the baseline only when they don’t have a number. Reread A Three-Year Horizon.

5. An integration that ran every night for a year stopped this morning. Nobody touched it. Where do you look first?

The other side of the boundary: a renamed field, a reset secret or token, an upgrade, a new platform release. Something changed on a side the integration crosses into. Reread Owners, Boundaries and Change.

6. A middleware team owned by another company will read and write Salesforce customers for years. Standard API or a contract you own?

Usually a contract you own, such as get customer and save customer, so you can change the fields and objects behind it without breaking them. The standard API works for a small team that sits together and joins your meetings. Decide in the first weeks. Reread What Breaks When One Side Changes.

7. A subscriber to platform events is down from Friday evening until Tuesday morning. What happened to Friday's events, and how do you recover?

They’re past the 72-hour retention window, so they’re gone, with no error to tell you. Recover with the bulk path you planned in advance: a big load to bring the system up to date, incremental loads to close the gap, then switch back to the events. Reread At What Point Is It Data Loss?

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.