Recommended Free Tools
CRM automation typically separates publishing an event from the work a subscriber performs after receiving it. A queue can absorb work and decouple those stages, but it does not by itself guarantee prompt execution, exactly-once effects, or a universal retry policy. To see how the lifecycle works in practice, this guide uses Salesforce platform events for the detailed example and distinguishes publish retries from subscriber retries. The short comparison with Dynamics 365 Finance and Operations shows how configurable endpoints create a different architectural choice.
How do CRM automation events get queued and processed?
Think of an event as a message that reports something happened—for example, an order was submitted or a case changed. A publisher creates the event; a subscriber receives it and performs business logic. In Salesforce’s high-volume platform-event model, those are separate stages:
As an Amazon Associate I earn from qualifying purchases.
- Producer transaction: An API, Apex code, or point-and-click automation publishes an event.
- Publish request queue: After successful submission, the request is queued for asynchronous processing.
- Event bus: Salesforce saves the event when resources are available.
- Subscriber: An Apex trigger, Flow, or external client using the Pub/Sub API receives the event.
- Business action: The subscriber performs its work, such as updating records or calling another service.
The queue and event bus decouple the publisher from downstream processing. They are not one shared queue with one universal retry counter: Salesforce documents a retry mechanism for internal event publishing and separate behavior for subscriber failures. The Salesforce Developers Enterprise Messaging Platform Events guide describes the high-volume event path and internal publish retries as at-least-once. That means a publish may be attempted again; downstream side effects should be designed to tolerate duplicate processing rather than assume exactly-once delivery.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Does Salesforce guarantee when queued events will run?
No. Salesforce describes asynchronous execution as unpredictable because requests share instance resources across organizations. Its Help article Description of Asynchronous processing in Salesforce, published June 14, 2026, states: “There is no Service Level Agreement (SLA) for when an asynchronous process will execute or finish.” Queueing is useful for buffering and decoupling, not a promise of real-time or prompt completion.
#1 Best Overall
How does Salesforce retry platform event triggers?
Salesforce Apex platform-event triggers can signal that a failure may be temporary by throwing EventBus.RetryableException. Salesforce’s Retry Event Triggers with EventBus.RetryableException guide says this can suit transient errors or conditions external to the event records that may later clear. The retry resends the batch after a small delay, with delays increasing on subsequent attempts. A failed trigger invocation’s DML is rolled back before the retry.
| Behavior | Salesforce Apex platform-event trigger |
|---|---|
| Retry trigger | Throw EventBus.RetryableException for a qualifying failure; resends occur after increasing delays. |
| Batch and ordering on resend | The resend retains ReplayID ordering, but the batch size can differ from the failed invocation. |
| Maximum attempts | 10 executions total: the initial execution plus at most nine retries. |
| At the limit | The trigger enters an error state and stops receiving new events. Events published while it is stopped are not resent to that trigger. |
| Recovery | Correct and save the trigger to resume processing. Salesforce recommends fewer than nine retries. |
These limits are specific to the documented Salesforce Apex trigger behavior; they are not a general CRM or queue-product retry policy. Operators should also plan how to identify a halted trigger and reconcile work published during its stopped period, because resuming the trigger does not automatically resend those events.
Are Salesforce Flow retries the same as Apex trigger retries?
No. Salesforce Help’s Troubleshooting Flow Retries documentation distinguishes retry behavior by Flow type. In its retry matrix, platform-event-triggered flows and Data Cloud-triggered flows do not receive the described time-based retry. Some other Flow types do use scheduled retry intervals:
Free tools Windows power users keep installed
One-click scans. No signup required.
| Salesforce Flow behavior | Documented retry treatment |
|---|---|
| Platform-event-triggered and Data Cloud-triggered flows | No time-based retry in the documented matrix. |
| Some after-commit record-triggered flows, scheduled paths, schedule-triggered flows, and wait-based flows | Retries at 15-, 30-, 60-, and 120-minute intervals; after those intervals, the interview fails. |
| Callout and record-update scenario described by Salesforce | If a batched interview’s callout fails before Salesforce records are updated, the failing interview is neither rolled back nor retried. If both callouts succeed but one record update fails, the successful flow can roll back and retry, up to two retries. |
Callouts themselves cannot be rolled back. Salesforce advises using a Flow fault path to handle an element error when the goal is to ensure the interview does not fail and a retry is not attempted. These details are Salesforce Flow guidance, not interchangeable with Apex trigger behavior.
What do ordering and event retention mean for recovery?
Salesforce’s Enterprise Messaging Platform Events guide sets a boundary around ordering: order is preserved among events sent in one publish call, but not guaranteed across separate publish requests. Separate requests may be processed by different Salesforce application servers, so arrival order across requests is not a safe business-sequencing rule. Stored events are delivered according to ReplayID values. If cross-request sequence matters, use an explicit sequence or versioning design in the business data rather than infer sequence from arrival time.
| Salesforce event type | Documented message retention | Source |
|---|---|---|
| High-volume platform events | 72 hours (3 days) | Salesforce Developers, Enterprise Messaging Platform Events |
| Legacy standard-volume platform events | 24 hours (1 day) | Salesforce Developers, Enterprise Messaging Platform Events |
Retention establishes a window in which stored messages are available for replay; it is not proof that every downstream system completed its business action. Salesforce describes high-volume events as designed to publish and process millions of events efficiently, but that is not a throughput benchmark for a particular org or a latency commitment.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What changes with Dynamics 365 Finance and Operations?
Microsoft documents a configurable endpoint model for Finance and Operations business events, including Azure Service Bus Queue and Topic, Event Grid, Event Hub, HTTPS, Power Automate, and Dataverse. This differs from treating the CRM’s native event bus as the central delivery path: the selected endpoint is part of the architecture.
- Azure-based endpoints must be created in the customer’s Azure subscription; Finance and Operations does not provision them. Azure services may involve separate costs.
- When Power Platform integration is enabled, supported endpoints can sync to Dataverse and be proxied through it.
- Some endpoint types continue to receive events directly from Finance and Operations if they are unsupported in Dataverse or the integration is not enabled.
Microsoft Learn’s Manage business event endpoints – Finance & Operations documents endpoint options and integration conditions, but does not establish one comprehensive retry policy for all of them. Retry, retention, ordering, and dead-letter behavior must be checked for the particular endpoint and platform configuration.
What should teams check before choosing an event design?
Compare the whole operating model, not only whether a product has a queue. For the selected CRM edition, API version, and endpoint, establish:
- Decoupling: Whether the publisher can complete independently of subscriber work, and where each stage is buffered.
- Retry scope: Whether retry applies to publishing or consumer execution, what errors qualify, the maximum attempts, and how delays are determined.
- Transactions and duplicates: What rolls back on failure, what cannot be rolled back, and how subscribers make external side effects idempotent.
- Ordering: Whether ordering applies within a batch, request, partition, or across independent requests; add explicit sequence data when business order must be enforced.
- Replay and recovery: How long messages remain available, how operators detect stopped consumers, and how missed work is reconciled.
- Operations and capacity: What monitoring exists, what latency or capacity commitments actually apply, and who provisions and pays for external endpoint infrastructure.
These checks matter because a successful publish, a stored event, and a completed subscriber action are different outcomes. An architecture should make each one observable and define a recovery path for failures at each stage.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
