Study guide

Study guide for chapter 15 of the Integration Architect course. Read the eight 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 about work that spans systems: who coordinates it, what the user sees while it runs, and how you take it back when a step fails. It has no exam objective of its own; it supports choosing the pattern (DES-1) and the trade-offs of a design (DES-3). The two ideas the exam leans on: there’s no rollback across systems, and a callout can’t wait on a standard Save.

For the Exam

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

One call, many steps (DES-1, DES-3)

I know one call to the middleware can stand for several steps, each committed on its own, so it only looks like one transaction. (It Only Looks Like One Transaction)
I design for every combination, including no answer at all, and make the answer say which steps happened. (The Worst Answer: No Answer, An Answer That Says Which)

The user waits (DES-1)

I know a callout can’t run while a user waits on a standard Save, so a synchronous check needs its own screen: a screen flow that calls before it saves, or a Lightning web component with Apex (a continuation for long waits). (Why the Standard Save Can’t Do It, Two Ways to Build It)
I know a Screen, local action or Wait element ends a flow’s transaction and starts a new one. (Where the Transaction Ends)
I know when it’s too slow for a screen: submit, and tell the user later. (When It’s Too Slow for a Screen)

No rollback across systems (DES-3)

I know a Salesforce transaction rolls back as a whole (savepoints for part of it), but separate systems each commit their own work. (Inside Salesforce, Undo Is Built In, Across Systems, There’s No Shared Undo)
I give the work a status that shows it isn’t finished, and trade for eventual consistency with a limit and an owner. (The State in Between, Eventually, With an Owner)

Orchestration or choreography (DES-1, DES-3)

I know choreography is publish and subscribe: the publisher doesn’t know its subscribers, so systems stay loosely coupled. (What Choreography Gives You, and Costs)
I know orchestration fits dependent steps, one place that knows each transaction’s status, and coordinated recovery. (What a Conductor Gives You, and Costs)
I choose per piece of work, by who needs to know where the work is. (Choosing)

The saga and the undo step (DES-3)

I undo completed steps with compensating steps (cancel, release, refund), in reverse order. (Every Step Has an Undo)
I put steps that can’t be undone last, after the point of no return. (Some Steps Can’t Be Undone)
I make every undo safe to retry, because it can fail too. (The Undo Can Fail Too)

Where the conductor lives (DES-1, DES-3)

I know the homes: Salesforce (Flow Orchestration for multi-step, multi-user processes; asynchronous Apex), the middleware (routing, transformation, security and errors across systems), or a workflow engine. (Inside Salesforce, In the Middleware, In a Workflow Engine)
I know coordinating several outside systems from Salesforce spends Salesforce’s own limits on every call. (Choosing Where It Lives)

Long waits and people (DES-1)

I save the state and pause (a flow’s Wait element, or an orchestration’s interactive step), never holding a transaction or callout open. (A Wait Is Saved State, Not an Open Call)
I give every wait a deadline as well as the answer. (Every Wait Needs a Deadline)
When a callback doesn’t arrive, I check the outcome before resending. (The Step That Never Answers)

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.

An answer that says which steps happened, never just success or failure.
The person waits for the screen, never for the system.
Every in-between state has a meaning, a limit and an owner.
Choose orchestration or choreography per piece of work.
Every step has an undo, named before you need it.
Every wait has two ways out: the answer and the deadline.
Agents are conductors too (module 8, new and fast-moving): an undo for every action they can call, and the same key on a retry.

Words to Know

Term	In one line
Orchestration	One conductor knows the whole process
Choreography	Each system reacts to events; nobody in the middle
Compensating step	A new step that undoes an earlier one
Saga	A chain of local steps, each with its undo
Point of no return	The step after which the saga goes forward, not back
Eventual consistency	The systems agree later, within a limit, with an owner
Screen flow	A flow with screens, which can call out before it saves
Flow Orchestration	Salesforce’s multi-step, multi-user process conductor
Workflow engine	A conductor that keeps a process’s state through failures
Wait element	A flow pause that saves its state until a resume event

Check Yourself

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

1. The middleware checks the balance, submits the order and updates inventory in one call. The call times out. Did the order go through?

You don’t know. Design the answer to say which steps happened, and when there’s no answer, ask before you act again. Reread The Worst Answer: No Answer.

2. The business wants Save to check the customer's balance in accounting and block the save if it's overdrawn. How do you build it?

Not on the standard Save: a trigger can’t call out there. A screen flow or a Lightning web component checks first, shows the answer, then saves. Reread Why the Standard Save Can’t Do It.

3. The ERP accepted the order, then inventory failed. What rolls back the ERP's order?

Nothing, by itself. There’s no rollback across systems: a compensating step cancels the order in the ERP, and the order’s status shows it isn’t finished until then. Reread Across Systems, There’s No Shared Undo.

4. Three systems need to react to a new delivery status, and nobody needs to track the whole process. Orchestration or choreography?

Choreography: publish the event, let each system react, and keep them loosely coupled. If someone must know where each piece of work is, that’s a conductor. Reread Choosing.

5. A process reserves stock, charges a card and sends a confirmation email. In what order, and why?

Undoable steps first (reserve), the point of no return next (charge), and what can’t be undone last (the email), so a failure never leaves a message you’d have to take back. Reread Some Steps Can’t Be Undone.

6. Five of the six steps are calls to outside systems. Where should the conductor live?

Where most of the steps are: the middleware, not Salesforce, which would spend its own limits on every call. Reread Choosing Where It Lives.

7. A discount waits for a manager's approval, and the manager is away for two weeks. What did the design forget?

A deadline: every wait needs one, with a decision on it, such as remind, escalate, decide by default, or undo. Reread Every Wait Needs a Deadline.

8. A partner accepted a request with `202 Accepted` and never called back. Do you send it again?

Not first. Ask the partner what happened to that request, by its key; the callback may be lost, not the work. Then carry on, resend safely, or undo. Reread The Step That Never Answers.

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.
microservices.io, Pattern: Saga (opens in a new tab): the saga and its compensating transactions.