MuleSoft Salesforce Error Handling: Retries, Reconnection, and What Not to Retry
A retry policy is not an error-handling strategy. Production Salesforce integrations need to classify failures before deciding whether another attempt is useful.
Three useful failure classes
1. Transient technical failures
Examples include temporary connectivity loss and service unavailability. A bounded retry with backoff may be appropriate when the operation is safe to repeat.
2. Authentication and authorization failures
Expired/invalid credentials, revoked access, or insufficient permissions usually require configuration or security remediation. Infinite retry loops do not fix permissions.
3. Deterministic data/business failures
Required fields, validation rules, invalid picklist values, malformed IDs, and business-rule violations generally need data correction or reconciliation.
Reconnection is not business retry
Mule connector reconnection handles connectivity at the connector level. A business operation that failed after reaching Salesforce may require a different recovery decision. Keep those concepts separate.
Make retries idempotent
Before retrying a create/update workflow, ask whether repeating it can duplicate a record or side effect. Prefer external IDs and upsert where appropriate, and attach a durable business/correlation ID to observability records.
Error Hospital pattern
For recoverable but non-immediate failures, a durable error store is often better than holding the original request open:
Salesforce operation fails
→ classify
├─ transient + safe → bounded retry
└─ unresolved → error store / DLQ
→ inspect/correct
→ controlled replay
Store enough context to reproduce the operation safely without exposing secrets.
Avoid retry storms
When Salesforce is degraded, hundreds of workers retrying aggressively can amplify the outage. Use exponential backoff/jitter where appropriate, bounded concurrency, and circuit-breaking or workload throttling at architectural boundaries.
Observe by error class
Dashboards should distinguish connectivity, authentication, Salesforce validation, rate/limit pressure, transformation, and downstream failures. One generic ERROR counter is rarely actionable.