Recovery and escalation for failed integrations
Recovery procedures per channel: bounded trigger retries and Resume vs Resume from Tip, Pub/Sub resubscribe and republish by correlationKey, failed outbound message Retry, Bulk API 2.0 failed results, CDC gap and overflow events, ETL error tables, Publish Immediately error logs and caller-side Request and Reply errors.
Given a use case, identify the appropriate error handling, escalation and recovery procedures for a failed integration.
~8 min read · 10 practice questions ·
What the exam expects
- Bound platform event trigger retries, escalate before the error state, and choose Resume or Resume from Tip for a suspended subscription.
- Recover a Pub/Sub API subscriber or publisher after an error without skipping, duplicating or flooding.
- Recover failed outbound messages and failed Bulk API 2.0 records with the documented manual steps.
- Handle Change Data Capture gap and overflow events in a replication subscriber.
- Apply the integration patterns' error handling: ETL control and error tables, error logs that survive rollback, and caller-side handling in Request and Reply.
Key terms: error state (a trigger subscription that stopped after its last retry), tip (the newest position in the event stream), Replay ID (an event's position in the event bus), correlationKey (the Pub/Sub field that matches a publish result to its event), gap event (a header-only notice that a change event couldn't be generated), control table (ETL table storing run state for restart).
Key facts
- Detail
- Initial run plus 9 retries, then error state
- Detail
- Events sent while in error aren't resent to the trigger
- Detail
- Earliest event still in the bus; Resume from Tip = new events
- Detail
- Resumes from the tip
- Detail
- Backoff, limited attempts, CUSTOM + stored Replay ID
- Detail
correlationKey=ProducerEvent.id
- Detail
- Up to 24 hours, then failed queue; Retry gives 24 more hours
- Detail
failedResultsCSV withsf__Error,sf__Id, original fields
- Detail
- Changes beyond 100,000 in one transaction, one event per entity
- Detail
- Log, retry, terminate, notify; restart the ETL process
Sources for this section (7)
- Retry Event Triggers with EventBus.RetryableExceptiondeveloper.salesforce.com (opens in a new tab)
- View and Manage an Event's Subscribersdeveloper.salesforce.com (opens in a new tab)
- Retry Long-Lived RPC Calls After an Error Occursdeveloper.salesforce.com (opens in a new tab)
- Track the Delivery Status of an Outbound Messagehelp.salesforce.com (opens in a new tab)
- Get Job Failed Record Resultsdeveloper.salesforce.com (opens in a new tab)
- Transaction-Based Replication Stepsdeveloper.salesforce.com (opens in a new tab)
- Batch Data Synchronizationdeveloper.salesforce.com (opens in a new tab)
- Why keep a trigger's retries below 9?
- When should a Pub/Sub subscriber resubscribe with LATEST?
- Why store an overflow event's Replay ID?
- Who handles errors in Request and Reply?
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 (10 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams