Error handling for events, Apex jobs and APIs
Match each integration option to its documented error-handling mechanism: publish results and callbacks for platform events, checkpoints and retryable exceptions for event triggers, Pub/Sub API stream retries and flow control, finalizers and BatchApexErrorEvent for Apex jobs, partial success for REST collections, and retry rules by failure type.
Given a use case, determine error handling for different integration options.
~8 min read · 12 practice questions ·
What the exam expects
- Handle platform event publishing failures from Apex: inspect each
Database.SaveResult, retry temporary errors, and use a publish callback for the final result. - Choose between
setResumeCheckpoint()andEventBus.RetryableExceptionin an event trigger, and explain what happens when a trigger reaches the error state. - Recover Pub/Sub API publish and subscribe streams after errors, size fetch requests with flow control, and route each error code to automatic retry or to an engineer.
- Attach recovery to Apex jobs: Transaction Finalizers for Queueable jobs,
BatchApexErrorEventfor Batch Apex. - Design API error handling:
allOrNone=falsepartial success, retry strategy by failure type, and logging and rollback standards.
Key terms: publish callback (Apex class that receives the final, asynchronous publish result); resume checkpoint (replay ID after which a failed trigger restarts); error state (a trigger that exhausted its retries and stopped receiving events); flow control (a Pub/Sub client requests only as many events as it can process); Transaction Finalizer (a System.Finalizer that runs after a Queueable job ends); partial success (valid records commit while failed ones return errors).
Key facts
EventBus.publish() exceptions- Detail
- None for failed publishes; inspect each SaveResult
- Detail
OPERATION_ENQUEUED: queued, not finally published
- Detail
- High-volume events only; run as Automated Process
- Detail
- Initial run plus 9 retries, then error state
- Detail
- Not resent; fix and save the trigger
- Detail
- 1,800 seconds, then CANCELLED
- Detail
- 100 across all fetch requests
- Detail
- 5 consecutive failures; counter resets on success
- Detail
- Needs
Database.RaisesPlatformEvents; fires for limit exceptions
allOrNone default- Detail
- false; up to 200 records per request
Sources for this section (8)
- Publish Event Messages with Apexdeveloper.salesforce.com (opens in a new tab)
- Apex Publish Callbacksdeveloper.salesforce.com (opens in a new tab)
- Retry Event Triggersdeveloper.salesforce.com (opens in a new tab)
- Handle Errorsdeveloper.salesforce.com (opens in a new tab)
- Pull Subscription and Flow Controldeveloper.salesforce.com (opens in a new tab)
- Transaction Finalizersdeveloper.salesforce.com (opens in a new tab)
- Firing Platform Events from Batch Apexdeveloper.salesforce.com (opens in a new tab)
- Update Records Using sObject Collectionsdeveloper.salesforce.com (opens in a new tab)
- Why can't a try-catch block around `EventBus.publish()` detect failed publishes?
- When should a platform event trigger throw `EventBus.RetryableException` instead of setting a checkpoint?
- What must a Pub/Sub API client do after any error ends its Subscribe stream?
- Why does a batch job implement `Database.RaisesPlatformEvents` instead of catching exceptions?
- When should a REST integration set `allOrNone` to false?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Integration Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 25 lessons of the Integration Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (12 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams