Study guide

Study guide for chapter 14 of the Integration Architect course. Read the nine 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 the whole Maintain section of the exam (monitoring, escalation and recovery, reporting) and two Build objectives: error handling and resilience to releases. It starts from one habit: for every arrow out, where do I log, who do I tell, how do I retry; for every arrow in, how will they retry and recover?

For the Exam

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

Every arrow, out and in (BLD-4)

For every outbound arrow I can answer: where do I log, who do I tell, how do I retry. (Every Outbound Arrow)
For every inbound arrow I ask how they’ll retry and recover, and make my side safe to repeat. (Every Inbound Arrow)
I know who owns the error by pattern: Request and Reply, the caller; Fire and Forget, only the hand-off, with any retry custom; platform events, the subscriber replays; Remote Call-In, the remote system, with my side idempotent; batch, control and error tables and a restart. (Who Owns the Error, Pattern by Pattern)
I know the exam’s usual answer puts most handling in the middleware, and that each layer still has its part. (Top to Bottom)

Capture everything (BLD-4, MNT-1)

I know what one log entry holds, and that one shared ID through every layer lets me read the logs side by side. (What One Entry Holds, One ID, Through Every Layer)
I know a log written in a transaction that rolls back is lost, and the ways around it: a platform event with Publish Immediately, or Database.insertImmediate() to a big object. (The Log That Rolls Back)
I know big objects for logs at volume: insert-only, queried by an index that can’t change after deployment, no triggers, flows or standard UI. (At Volume)

The log is data (MNT-2)

I plan retention from day one: archive or discard “at the same rate at which it comes into the system”. (A Log Fills Up, Two Phases, Then Three Tiers)
I know the purge mechanics: custom object deletes go through the Recycle Bin; big object rows go with deleteImmediate(), naming every index field. (Purging at Volume)
I decide field by field what the log may hold, hash what I need to match, and keep the list in settings, not code. (Decide What the Log May Hold)

Retries without duplicates (BLD-4)

I know retries in several layers multiply, so one layer owns the retry. (One Layer Retries, Not Every Layer)
I know Salesforce’s timeout guidance: 5 to 10 seconds where a user waits, 30 to 60 for asynchronous work. (A Timeout Sized to Who Is Waiting)
I know the circuit breaker’s three states (closed, open, half-open), its state kept in Platform Cache. (Stop Calling a System That’s Down)
I know where a retry goes when it stops: a dead letter channel, the to-do list a person sees, never nowhere. (Where a Retry Goes When It Stops)
I make the receiver safe against repeats and old news. (The Other End)

The return receipt (BLD-4, MNT-2)

I know platform event publishing is asynchronous and at least once: the publish result is only queueing, publish callbacks give the final result, and rarely an event isn’t kept at all. (Why a Platform Event Alone Isn’t Enough, Three Kinds of Sent)
I know proof of delivery needs my own tracking: what was sent, saved with the change (the transactional outbox), and an acknowledgment back. (The Industry’s Name: the Outbox)

Escalation and recovery (MNT-2)

I alert on patterns and thresholds, not single errors, with severity by user impact. (Alert on Patterns, Not Single Errors)
I alert on silence too: a run that never happened sends no error. (The Run That Never Happened)
Every integration has an owner and a runbook. (An Owner and a Runbook)
I know recovery in three sizes: replay one from my log, catch up from a stored replay ID within 72 hours, or resync since the last known-good point. (Recovery in Three Sizes)

What Salesforce shows you (MNT-1)

I know where to look: failed flow interviews on the Automation app’s Monitor tab; the allowance through /limits, Sforce-Limit-Info and API Usage Notifications. (Did the Automation Fail?, How Much of the Allowance Is Left?)
I know Event Monitoring’s event log files: API Total Usage free for 24 hours, other types kept 30 days (up to a year) with Event Monitoring; Composite API Subrequest events for a composite’s parts. (Who Called, How, and How Long Did It Take?)
I watch the slow tail, not the average, and know Scale Center and Threat Detection. (How Fast Is It, Really?, The Normal-Looking Call That Isn’t Normal)

Reporting (MNT-3)

I start from the reader: who needs which report. (Who Reads Which Report)
I know the measures: volume, error rate, latency, completeness, failures and their age, queue depth. (The Measures That Matter)
I set targets per business capability. (Targets Per Business Capability)
I know big object data is copied to a custom object to be reported on. (Where the Numbers Come From)

Resilience to releases (BLD-6)

I know Salesforce releases three times a year, and I pin and track my API version. (Three Times a Year, Your Version)
I know versions 31.0 to 40.0 are deprecated in Summer ‘27 and retired in Summer ‘28 (REST 410 GONE, SOAP UNSUPPORTED_API_VERSION, Bulk InvalidVersion); 21.0 to 30.0 retired in Summer ‘25; custom Apex REST and SOAP services aren’t affected. (Your Version)
I use Release Updates, the preview sandbox, and three kinds of test before every release. (Release Updates, Test Before Production Does, Three Kinds of Test)

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.

Every arrow, out and in. Ask the questions until it’s a habit.
One ID through every layer.
The log is data: a retention plan and a masking list from day one.
One layer retries. Every retry ends somewhere a person sees.
None is a number too. Alert on silence.
An owner with a name, and a runbook on one page.
Three times a year, the same checklist.

Words to Know

Term	In one line
Failure plan	One row per arrow: log, tell, retry, recover, owner
Integration log	Your own record of every call, with one shared ID
Big object	Salesforce storage for very large, insert-only data
Idempotent	Safe to receive twice
Circuit breaker	Stop calling a system that’s down, then try one call
Dead letter channel	Where work goes when its retries run out, for a person to see
Transactional outbox	What was sent, saved with the change that caused it
Return receipt	An acknowledgment that proves delivery
Runbook	One page for whoever holds the alert
Event Monitoring	Salesforce’s event log files of activity
Release Updates	Changes with a due date, listed in Setup
Preview sandbox	A sandbox upgraded weeks before production

Check Yourself

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

1. Apex catches an exception, writes an error to a log object, then rethrows. The log is always empty. Why?

The rethrow rolls back the whole transaction, the log record included. Log with a platform event set to Publish Immediately, or Database.insertImmediate() to a big object. Reread The Log That Rolls Back.

2. Salesforce retries three times, the middleware three times, and the partner's gateway three times. How many calls can one failure make?

Up to 27: retries multiply. One layer owns the retry; the others pass the failure on. Reread One Layer Retries, Not Every Layer.

3. The partner's system has been down for twenty minutes. Every status still tries, waits and fails. What do you add?

A circuit breaker: after enough failures it opens and stops calling, then lets one call through to test whether the system is back. Reread Stop Calling a System That’s Down.

4. `EventBus.publish` returned success. Was the event delivered?

No. That result only says it was queued. Publish callbacks give the final result, and only your own tracking with an acknowledgment proves delivery. Reread Three Kinds of Sent.

5. The admin gets a hundred integration emails a day and filters them away. What's the better design?

Alert on patterns and thresholds, with severity by user impact, to an owner with a runbook. Reread Alert on Patterns, Not Single Errors.

6. A listener was down from Friday night to Tuesday morning. How do you recover?

Past the 72-hour retention, replay can’t reach the start. Resync the changes since the last known-good point, then resume from the latest. Reread Recovery in Three Sizes.

7. Your integration log is a big object. The manager wants a weekly report. How?

Standard reports don’t run on big objects. Copy the counts or the failures into a custom object, and report on that. Reread Where the Numbers Come From.

8. An old integration calls the REST API on version 38.0. What happens, and when?

Versions 31.0 to 40.0 are deprecated in Summer ‘27 and retired in Summer ‘28; after that, REST returns 410 GONE. Find the caller with the API Total Usage log, and move it. Reread Your Version, at the Bottom of the List.

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.
Salesforce Architects, Well-Architected: Reliability (opens in a new tab): Salesforce’s own guidance on resilient design.