Outbound Message
An Outbound Message is a SOAP-based notification Salesforce sends to an external endpoint when a Workflow Rule or a Process Builder action fires.
Definition
An Outbound Message is a SOAP-based notification Salesforce sends to an external endpoint when a Workflow Rule or a Process Builder action fires. The message contains a fixed set of fields from the triggering record, formatted as SOAP XML, and is POSTed to a configured URL. The receiving endpoint acknowledges with a SOAP response; if Salesforce does not get the ack, it retries on a back-off schedule for up to 24 hours. Outbound Messages are the legacy declarative integration pattern, predating Flow, Platform Events, and Change Data Capture by a decade.
Outbound Messages live in Setup, Workflow Actions, Outbound Messages. They are still supported but are no longer the recommended pattern for new integrations. Salesforce documents Platform Events, Change Data Capture, and Apex callouts as the modern alternatives. Many production orgs still run Outbound Messages from the 2010s era; they work reliably and require no code, which is why they have survived multiple generations of platform changes. New integrations should default to Platform Events or REST callouts; existing Outbound Messages can stay until a migration project justifies the work.
How Outbound Messages send SOAP notifications without Apex, and why they are still around
The SOAP message format and what fields are sent
An Outbound Message is configured with a target endpoint URL and a list of fields from the triggering record. When the workflow fires, Salesforce builds a SOAP XML envelope with those fields, the record ID, the org ID, and a session ID (optional). The format is fixed; you cannot send custom JSON, REST payloads, or arbitrary headers. The receiving endpoint must speak SOAP and return an Ack response in the expected SOAP envelope shape, or Salesforce treats the message as failed.
Retry behavior and the 24-hour window
If the endpoint does not return a successful Ack, Salesforce retries on an exponential back-off schedule. First retry within seconds, then minutes, then hours, up to 24 hours from the original send. After 24 hours of failures, the message is marked failed permanently and shows in the Outbound Message Queue. Admins can manually retry failed messages from the queue UI. The retry behavior is one of the genuine reliability wins of Outbound Messages over a synchronous Apex callout, which fails on the first error without retry.
Configuration via Workflow Rules and Process Builder
Outbound Messages are invoked as a Workflow Action or Process Builder action. Build the Workflow Rule with the triggering criteria (Status changes to Closed), add the Outbound Message as one of the actions. When the rule fires, the message sends. Process Builder offers the same trigger pattern with richer criteria support. Flow does not natively support Outbound Messages; flow users typically invoke an Apex callout instead.
Why Salesforce moved past Outbound Messages
Three reasons the modern stack moved away. SOAP is verbose, slow to parse, and out of fashion compared to REST/JSON. The retry semantics, while reliable, do not give the receiver any context on retry counts or original timestamps. And the receiving system has to publicly expose a SOAP endpoint, which security teams resist. Platform Events, Change Data Capture, and webhook-style Apex callouts all addressed these limitations. Outbound Messages were not removed because too many legacy integrations depend on them.
Modern alternatives and when each fits
Three replacements. Platform Events for fire-and-forget event broadcasts; subscribers self-register, no point-to-point coupling. Change Data Capture for "tell me everything that changed on this object" patterns; the platform streams every change. Apex callouts (REST/JSON) for synchronous record-driven calls with full control over headers, payload, and error handling. The decision tree: event broadcast goes to Platform Events; row-level change feed goes to CDC; record-driven sync POST goes to Apex callout.
Migration considerations from legacy Outbound Messages
Many orgs maintain multi-year-old Outbound Message integrations. Migration requires the receiving system to expose a new endpoint (or the new pattern's subscriber registration), rebuilding the trigger logic in Flow or Apex, parallel-running both for a release cycle, and finally retiring the old. Plan the migration when you are touching the integration anyway (the receiving system is being rewritten, the workflow is being redesigned). Migrating purely for modernization rarely justifies the effort if the existing integration works.
Outbound Message Status and the failure queue
Setup, Monitoring, Outbound Messages shows pending and failed messages with their retry history. Admins can manually retry, delete, or audit failed messages. Persistent failures usually indicate the endpoint changed (URL moved, SOAP contract changed) or the receiver is rate-limiting. The queue is also where you see if a high-volume workflow is generating more messages than expected, which can throttle the receiving system.
Building an Outbound Message and wiring it to a workflow
Outbound Message setup has two pieces: define the message (target endpoint, fields to send) and add it as an action on a Workflow Rule or Process. The endpoint owner separately builds the SOAP receiver.
- Define the Outbound Message
Setup, Workflow Actions, Outbound Messages, New. Pick the object (Account, Case, custom). Set the endpoint URL (must be HTTPS in production). Select the fields to include in the SOAP payload. Save.
- Add to a Workflow Rule
Setup, Workflow Rules, edit or create a rule. Add the Outbound Message as one of the Immediate Actions or Time-Dependent Actions. The rule''s criteria determine when the message sends. Activate the rule.
- Provide the WSDL to the endpoint owner
From the Outbound Message detail page, click Click for WSDL. Send the WSDL file to the team building the receiver; they generate stub code from it. The Ack response shape is part of the WSDL.
- Test the integration
Trigger the workflow on a test record. Check the Outbound Message Status page for the delivery. If failed, inspect the retry history and the endpoint logs. Iterate on either the message field list or the receiver code.
- Monitor in production
Setup, Monitoring, Outbound Messages. Check the failure queue weekly. Persistent failures need either endpoint fixes or message-config updates. High-volume orgs may need to throttle the workflow to keep up with receiver capacity.
HTTPS URL of the SOAP receiver. Production endpoints must be HTTPS; sandbox can be HTTP for testing.
Specific fields from the triggering record. Pick only what the receiver needs; smaller payloads are faster and more secure.
Optional. Includes a Salesforce session ID in the SOAP envelope, allowing the receiver to call back into the Salesforce API as the workflow user. Use only when the receiver genuinely needs callback access.
The Salesforce user identity the message represents. Affects field-level security on the SOAP payload.
- Outbound Messages are SOAP, not REST. Receivers must implement the SOAP Ack envelope or Salesforce treats every message as failed.
- Retry runs for 24 hours, then permanently fails. Long endpoint outages cause data loss; build alerting on the failure queue.
- Flow does not natively support Outbound Messages. Use Apex callouts from flow instead, or fall back to a Workflow Rule (still supported alongside flow).
- Receiving endpoints must publicly expose a SOAP service. Security teams sometimes resist this; webhook-style modern integrations are easier to defend.
- The 24-hour retry window is the only reliability mechanism. There is no dead-letter queue, no message replay, no audit log of original payload values.
Trust & references
Cross-checked against the following references.
- Outbound Messages OverviewSalesforce Help
- Define an Outbound MessageSalesforce Help
Straight from the source - Salesforce's reference material on Outbound Message.
- Track Outbound Message StatusSalesforce Help
- Outbound Messaging Developer GuideSalesforce Developer Docs
Hands-on resources to go deeper on Outbound Message.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Outbound Message?
Q2. What's the modern alternative?
Q3. Why are Outbound Messages considered legacy?
Discussion
Loading discussion…