We are building an outbound message listener that expects large volumes and near real-time performance.

As we are working through our low-level design, we have two questions that are not crystal clear from the documentation.

Question 1. What is the amount of time before the first "retry" occurs.

The documentation ( https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_notifications.htm ) says "If a message cannot be delivered, the interval between retries increases exponentially, up to a maximum of two hours between retries." So I understand the upper bound of that retry interval, but what is the minimum? Meaning, we are planning on processing the message before sending the acknowledgement back to Salesforce, and I want to ensure that SLA for processing is less than the amount of time that will take place before the first retry occurs. Obviously, if processing time than the length of time before the first retry attempt occurs, then I have a problem as all records would be processed twice.

question #2: How long does outbound messaging “wait” as it bundles records / notifications before it sends a single message? Is it all qualifying records within one second? Two seconds? The millisecond level?

  • Considering it's Async, I don't think we offer any guarantee on time. For a Real time system, these async processes (outbound, batch apex etc) shouldn't be used. Let's say queue gets flooded then messages might be delayed even more.
    – sfdc rowdy
    Sep 29, 2016 at 15:11

1 Answer 1

  1. There's no documented minimum, and its subject to change, but its in the order of 2-5 seconds [depending on various things such as the performance of your endpoint]. However your latter comment highlights an issue, OM is at least once delivery, even if you ack the response that might not make it back to salesforce, and the messages will get delivered again, this is a very real condition your listener should handle [by tracking the recently processed notification Ids, and dropping already successfully processed messages].

  2. Highly variable, depends on both the performance characteristics of your endpoint, and server load, can be anywhere from 100ms to minutes.

I think in general these are good ballpark numbers to know, but your design shouldn't be particularly dependent on them.

  • I will add to @superfell saying that there is NO SLA around outbound messages and we have seen on Dec cereal occasions where the queue will freeze for several hours (the longest being 5+hrs). If you are relying on this data always flowing I would suggest that you use polling instead. Oct 2, 2016 at 1:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .