Salesforce Integration Error and Recovery Testing
Salesforce integration error and recovery testing deliberately breaks integrations to prove they fail safely and recover completely — that a timeout is retried, a rejected record lands somewhere visible, a redelivered message does not create a duplicate, and nothing is lost after an outage. SyntraFlow is designed to inject failures into realistic scenarios and then reconcile both ends to confirm the data is whole again.
Failure injection and recovery validation are available for demonstration and proof-of-concept validation.
Happy paths do not fail in production
Almost every integration is tested on the path where the endpoint is up, the token is valid and the data is clean. Production is different. Tokens expire, ERPs go into maintenance windows, row locks collide during nightly loads, a middleware node restarts mid-message and the org hits its daily API allocation at quarter end. What matters then is not whether the integration failed, but whether it failed in a way that can be seen and repaired without losing or duplicating data.
Error and recovery testing makes those conditions happen on purpose in a test environment. It asks three questions for each failure: was it detected and surfaced, was the transaction retried or parked correctly, and after recovery do Salesforce and the connected system agree? That last question is answered by reconciliation, which is why this page works hand in hand with data reconciliation testing.
This page covers failure behavior across every integration mechanism. For the mechanics of each API, see Salesforce API testing; for event-specific delivery and replay, see Platform Events testing.
Failures to inject and the recovery to expect
Each injected failure has a defined correct response. The test passes only when that response happens and the data reconciles.
| Injected failure | Expected handling | What reconciliation must show |
|---|---|---|
| Target endpoint unavailable | Retry with backoff, then park the message after the retry limit | Every parked message is delivered once the endpoint returns |
| Request timeout after the target committed | Retry uses an idempotency key or external ID so the target does not double-post | Exactly one target record per source record |
| Expired or revoked OAuth token | Token refreshed once and the call retried; a revoked token raises an alert | No records skipped during the authentication failure |
| Validation rule rejects an inbound record | Record routed to an error queue with the Salesforce error code, not retried endlessly | Rejected records are listed and none are silently lost |
| UNABLE_TO_LOCK_ROW during a load | Only the locked rows are retried after a delay | Final counts match the source with no duplicates |
| REQUEST_LIMIT_EXCEEDED | Calls throttled or deferred until allocation resets | Deferred work completes and is not dropped |
| Malformed payload from the source | Message rejected as a poison message and quarantined | Healthy messages behind it continue to flow |
| Subscriber offline for several hours | Subscriber resumes from its last stored replay ID or checkpoint | No gap in events within the retention window |
Running a recovery test end to end
SyntraFlow can be configured to wrap an ordinary integration scenario with a controlled fault and a recovery check.
Establish a clean baseline
Known records are created in Salesforce and, where needed, the target system, and a reconciliation confirms both sides agree before the fault is introduced.
Inject the fault
The failure is introduced in a controlled way — pointing a named credential at an unavailable stub, revoking a test token, seeding a record that breaks a validation rule, or pausing a subscriber.
Drive traffic through the failure
Real transactions are created while the fault is active, so the integration's retry, queueing and error paths are exercised with realistic data.
Assert the failure was visible
The test checks the error log object, middleware error queue, failed-results file or alert the team relies on, so a silent failure fails the test.
Remove the fault and trigger recovery
The endpoint is restored or the reprocess action is run, exactly as an operations team would during an incident.
Reconcile both ends
Counts and key field values are compared across Salesforce and the target, confirming nothing was lost and nothing was duplicated.
Recovery patterns and how to prove them
Resilient Salesforce integrations rely on a small set of patterns. Each one has a specific way of being wrong.
Idempotency via external IDs
Upsert on a unique external ID lets a retried create become an update. Tests resend the same message and confirm one record, and confirm the external ID field is actually marked unique.
Retries with backoff
Retries should space out and stop. Tests confirm the retry count and intervals, and that a permanent error such as a validation failure is not retried at all.
Dead-letter and error queues
Messages that exhaust retries must land in a dead-letter queue or error object with enough context to reprocess. Tests check the queue contents and the reprocess path.
Replay and checkpoints
Event subscribers store a replay ID or checkpoint. Tests stop a subscriber, publish events and confirm it resumes without gaps or duplicate processing.
Compensation for partial success
When step two of a multi-system transaction fails, step one must be reversed or flagged. Tests confirm no half-finished orders remain.
Apex trigger retries
Platform event triggers can throw EventBus.RetryableException to be retried a limited number of times. Tests confirm what happens when the final retry also fails.
Salesforce behaviors that shape recovery
Several platform behaviors decide whether a failure is recoverable at all. Recovery tests should account for each.
- Bulk API jobs can complete with failed rows, which are only available from the failed-results file — recovery depends on reading and reprocessing it, covered in Bulk API testing.
- REST composite and sObject Collections calls commit partial results unless allOrNone is set, so a retry of the whole request can duplicate the records that already succeeded.
- Outbound messages retry automatically for up to 24 hours, which means the listener must be idempotent.
- Platform events published immediately are not rolled back when the publishing transaction fails, while events set to publish after commit are only sent if it succeeds.
- Event bus retention is limited, so a subscriber outage longer than the retention window cannot be repaired by replay alone.
- Apex callouts cannot follow uncommitted DML, so error-logging designs that write a log record before calling out can themselves fail.
- The integration user's permissions must allow any reprocess action, which is worth checking with integration user testing.
Where recovery testing pays for itself
Order and billing integrations are the obvious candidates, because a lost order is lost revenue and a duplicate invoice is a customer complaint. The same discipline applies to customer master syncs, where a retried create can split one customer into two records in the ERP, and to HR-driven provisioning, where a missed termination leaves an active Salesforce user. The Salesforce–SAP and Salesforce–Workday pages describe those flows in detail.
Recovery tests are also worth running before a production hotfix that changes integration code, and after any change to middleware error handling. SyntraFlow is designed to keep these scenarios repeatable, so the unhappy paths are regression tested as routinely as the happy ones.
Evidence a recovery test should produce
Recovery testing is often required for operational readiness sign-off, so the evidence matters as much as the result.
| Evidence | Why it matters |
|---|---|
| Timeline of the injected fault and recovery | Shows how long the integration was degraded and when it caught up |
| Error records or queue entries captured | Proves failures were visible to the people who must act on them |
| Retry attempts and outcomes | Confirms retry limits and backoff behaved as designed |
| Before and after reconciliation | Demonstrates no data was lost or duplicated |
| Reprocess steps performed | Validates the runbook the operations team will follow in a real incident |
Related pages
Salesforce Integration Testing
The parent hub for APIs, events, middleware and cross-system validation.
Data Reconciliation Testing
The check that proves recovery left both systems in agreement.
Platform Events Testing
Delivery, replay and subscriber retries for event-driven flows.
MuleSoft Testing
Validate middleware error scopes, retries and redelivery by outcome.
Salesforce Bulk API Testing
Reprocess failed rows from high-volume loads safely.
Production Hotfix Validation
Confirm urgent integration fixes do not break recovery behavior.
Error & Recovery Testing testing FAQs
What is Salesforce integration error and recovery testing?
It is the practice of deliberately injecting failures into Salesforce integrations — unavailable endpoints, expired tokens, rejected records, lock contention, subscriber outages — and verifying that each failure is surfaced, retried or parked correctly, and fully recovered. The test ends with reconciliation to prove no data was lost or duplicated.
What does idempotency mean for Salesforce integrations?
An idempotent integration can process the same message more than once and still produce a single correct result. In Salesforce this is usually achieved with upsert on a unique external ID, so a retried create updates the existing record instead of inserting another. Tests prove it by resending identical messages and checking the record count.
Should every integration error be retried?
No. Transient errors such as timeouts, row locks and temporary unavailability should be retried with backoff. Permanent errors such as a validation rule failure or a missing required field will fail every time, so they should go straight to an error queue for correction. Tests confirm the integration tells the two apart.
What is a dead-letter queue in a Salesforce integration?
A dead-letter queue holds messages that could not be processed after the allowed retries. It usually lives in the middleware layer, though some teams use a custom error object in Salesforce. Recovery tests confirm failed messages arrive there with enough context and that the reprocess path delivers them correctly.
How do you test recovery after a subscriber outage?
Stop the subscriber, publish events or make record changes, then restart it and confirm it resumes from its stored replay ID or checkpoint. Every event within the retention window should be processed exactly once. Outages longer than the retention window need a separate catch-up process, which should also be tested.
Can SyntraFlow inject failures into a live production integration?
Failure injection belongs in sandboxes and test environments, not production. SyntraFlow is designed to introduce controlled faults in those environments, drive realistic transactions through them and reconcile the outcome. The specific injection methods for your landscape are agreed during a proof of concept.
Prove your integrations recover cleanly
See how SyntraFlow is designed to inject failures, verify retries and idempotency, and reconcile both systems after recovery.