ChatGPT
Perplexity
Claude
Google AI
Salesforce Outbound Message: Setup, Limits and What to Use Instead
Salesforce outbound message is one of the oldest integration tools on the platform, and plenty of orgs still run it. If you inherited one of those orgs, you’ve probably opened a workflow rule, found a strange SOAP endpoint attached to it, and wondered whether it was safe to touch.
This guide explains what a Salesforce outbound message does, how to build one, where it fails quietly, and what most teams pick today.
What a Salesforce outbound message actually is
It’s an action that sends a SOAP message over HTTP or HTTPS to an endpoint you choose, whenever a record meets the criteria you set. Originally it hung off workflow rules. You can now trigger it from Flow as well, which matters because Salesforce has been steering everyone away from workflow rules and toward Flow.
One SOAP message can carry up to 100 notifications, and each notification points to a record and the fields you selected.
The part people get wrong is delivery. Salesforce doesn’t consider a message delivered until the receiving server answers with a specific XML acknowledgment. If that reply never comes, Salesforce assumes the message failed and tries again. Retries slow down over time, with the gap growing up to about two hours, and everything stops after 24 hours.
This bites people during testing. A quick tool like a webhook catcher will happily receive your payload, but it won’t send the acknowledgment. So the data arrives, the Salesforce queue still shows a failure, and Salesforce keeps resending the same message. Nothing is broken on your side. The endpoint just isn’t answering the way Salesforce expects.
How to set up a Salesforce outbound message
- Decide what should trigger it. In Setup, create a workflow rule on the object you care about (Lead, Account, Opportunity), or use a Flow if your org has moved on from workflow rules.
- Write the criteria, such as a field changing to a certain value or a field no longer being blank.
- Add the action and choose New Outbound Message.
- Pick the fields to send and paste in the endpoint URL. Decide whether to include the session ID. Only include it if the receiver really needs to call back into Salesforce.
- Activate the rule.
To watch what happens afterwards, open Setup and go to Monitoring, then Outbound Messages. Each queued message is listed with its attempt count and next retry time.
Outbound message vs. platform events vs. Apex callouts
| Â | Outbound message | Platform events | Apex callout |
|---|---|---|---|
| Format | SOAP XML only | Publish/subscribe event bus | REST, SOAP or plain HTTP |
| Code needed | ✔ No | ✔ No, Flow can publish | ✗ Yes, Apex |
| Built-in retry | ✔ Yes, up to 24 hours | ✗ Subscribers replay from the event log | ✗ You write it yourself |
| Several receivers | ✗ One endpoint | ✔ Many subscribers | ✗ One endpoint per call |
| Timing | Asynchronous | Asynchronous | ✔ Can be synchronous |
| Replay/history | ✗ None | ✔ Replay ID, 72-hour window | Depends on your code |
| Best fit | Old SOAP systems, simple push | Decoupled, multi-system setups | Real-time request and response |
The short version is that outbound messages won the low-code prize for years because retries came free. The catch is that the other side has to run a SOAP service, and that feels heavy now. Platform events work more like a broadcast channel: many systems can listen, and a subscriber that was offline can catch up afterwards. Outbound messages can’t do that.
Where outbound messages let you down
- No audit trail. Once a message is delivered or dropped, the history is gone. It can also arrive more than once, or not at all if the endpoint stays down past 24 hours.
- Order isn’t guaranteed. Each message retries on its own schedule, so a later change can land before an earlier one.
- Stale is impossible, fresh is guaranteed. If the record changes while a message waits in the queue, the receiver gets only the latest values, never the in-between state that triggered the alert.
- SOAP or nothing. Your receiving system needs a SOAP listener that returns the right acknowledgment. For a REST-first team, that’s a lot of extra work.
- A hard 24-hour limit. After a day of failures, the message is removed. You can press Retry in the monitoring screen to move the next attempt to now, but only while the message still exists.
When a Salesforce outbound message still makes sense
Don’t rip them out just because they’re old. They’re a fair pick when the target already speaks SOAP, when you want retries without writing code, or when you’d rather not spend Apex callout limits. If yours works, leave it alone and write down what it does.
When you need to reach a person, not a system
Everything above is about moving data between systems. But many “tell someone when a record changes” requests are really about people. A rep wants a text when a lead converts. A donor should get a WhatsApp confirmation when a gift clears. A patient needs an SMS when an appointment moves.
Wiring that through a Salesforce outbound message means building a SOAP listener whose only job is to forward a message to a texting API. That’s a lot of plumbing for something that should be one step.
MessageBlink skips the plumbing. It’s a Salesforce-native SMS and WhatsApp app, and it fires from the same Flow or workflow logic your admins already use. There’s no external endpoint to host, no SOAP envelope, and no retry code to maintain.