Build Solution23% of the exam

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.

Official exam objective
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() and EventBus.RetryableException in 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, BatchApexErrorEvent for Batch Apex.
  • Design API error handling: allOrNone=false partial 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
Successful SaveResult
Detail
OPERATION_ENQUEUED: queued, not finally published
Publish callbacks
Detail
High-volume events only; run as Automated Process
Trigger retry cap
Detail
Initial run plus 9 retries, then error state
Events during error state
Detail
Not resent; fix and save the trigger
Publish stream idle timeout
Detail
1,800 seconds, then CANCELLED
Max events requested per Subscribe call
Detail
100 across all fetch requests
Finalizer re-enqueues
Detail
5 consecutive failures; counter resets on success
BatchApexErrorEvent
Detail
Needs Database.RaisesPlatformEvents; fires for limit exceptions
sObject Collections allOrNone default
Detail
false; up to 200 records per request
Sources for this section (8)
  • 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

Practice for the Integration Architect exam