Workflow Outbound Message
A Workflow Outbound Message in Salesforce is one of the four action types a Workflow Rule can fire when its trigger criteria are met.
Definition
A Workflow Outbound Message in Salesforce is one of the four action types a Workflow Rule can fire when its trigger criteria are met. The action sends a SOAP XML message containing record field data to a specified external endpoint URL when the workflow rule fires. The platform handles authentication (through an optional session id), retry behavior (up to 24 hours with exponential backoff), and message queuing if the external endpoint is temporarily unavailable. Outbound Messages were a common integration pattern in the 2010s for pushing record changes to external systems without writing Apex code.
In 2026, Workflow Outbound Messages are part of a deprecated automation toolkit. Salesforce announced the retirement of Workflow Rules in favor of Flow as the single declarative automation platform. Flow supports a similar outbound capability through HTTP Callout actions (with Named Credentials for authentication). Existing Workflow Outbound Messages continue to fire, and Salesforce has not set a hard end-of-support date, but no new investment goes into the technology. Plan migration to Flow on a per-rule basis as Workflow Rules retire.
Workflow Outbound Messages in 2026: legacy mechanics, queue behavior, and the Flow alternative
What a Workflow Outbound Message actually does
When a Workflow Rule fires and includes an Outbound Message action, the platform builds a SOAP envelope containing the source record fields (configured per Outbound Message) and posts the envelope to the configured endpoint URL. The envelope is structured XML matching the org Enterprise WSDL schema for the source object. The receiving external system parses the XML, processes the record data, and returns an acknowledgement SOAP response. If the response indicates success, the message is removed from the queue. If the response indicates failure (or the endpoint times out), the platform retries with exponential backoff for up to 24 hours before giving up. Outbound Messages run asynchronously; the source record save completes before the message is delivered.
Configuration: endpoint, fields, and user identity
Each Outbound Message has a defined endpoint URL, a list of fields to include in the SOAP envelope, a session id flag (whether to include the firing user session id for authentication), and a notification email for failures. Configure these in Setup, Workflow Outbound Messages. The endpoint URL must support SOAP and accept the auto-generated envelope schema. The field list determines which record fields the external system receives; selecting too few omits data the integration needs, selecting too many wastes bandwidth and increases coupling. Session id inclusion is optional; for endpoints behind a firewall on the company network, the session id is rarely needed; for cross-cloud calls, it can simplify authentication. Notification email for failures should route to the integration owner.
The Outbound Messages queue and the retry behavior
Outbound Messages run through an internal Salesforce queue. The queue holds undelivered messages and retries them on a schedule. Salesforce admins can inspect the queue through Setup, Outbound Messages Delivery Status to see pending, failed, and delivered messages. The platform retries each failed message with exponential backoff: 15 seconds, 30 seconds, 1 minute, doubling up to a maximum interval. After 24 hours of failed retries, the platform stops retrying and marks the message as failed permanently. The admin can manually re-queue a failed message after fixing the underlying issue (endpoint downtime, authentication change, schema mismatch). For business-critical integrations, monitor the queue weekly and triage any non-trivial failure backlog.
Workflow Outbound Message vs Flow HTTP Callout
Flow provides the modern equivalent through HTTP Callout actions inside a Flow. The Flow Callout supports REST instead of SOAP, accepts JSON instead of XML, integrates with Named Credentials for cleaner authentication, and benefits from the broader Flow investment (rich error handling, retry logic, conditional branching). For new outbound integrations, use Flow HTTP Callout. For existing Workflow Outbound Messages, migrate during the Workflow Rules to Flow migration project. The migration is not automatic; the Migrate to Flow tool generates an Apex action for the equivalent callout, which works but is less idiomatic than a native Flow Callout. Plan the rewrite carefully for high-volume or business-critical outbound integrations.
Receiving side: what the external endpoint needs
The external endpoint receiving the Outbound Message needs three things. First, a SOAP-capable HTTP server that accepts POST requests with XML payloads. Second, parsing logic that extracts the record fields from the SOAP envelope. Third, a SOAP response that returns an acknowledgement (specifically, a SOAP fault if processing failed, a success response otherwise). Most modern integration tools (Mulesoft, Workato, Boomi, Jitterbit) handle these requirements through pre-built Salesforce Outbound Message connectors. Custom-built endpoints need to implement them explicitly. The endpoint must respond within the platform timeout window (typically 10 seconds for synchronous processing); long-running processing should acknowledge quickly and queue the work for async handling on the receiving side.
Security, certificates, and the endpoint trust chain
Outbound Messages travel over HTTPS by default. The platform validates the endpoint TLS certificate against its trusted certificate store; self-signed certificates need explicit Cert Authority registration in Salesforce Setup. For endpoints requiring client certificate authentication, configure a Certificate in Setup and reference it on the Outbound Message. The session id (if included) is a powerful credential; treat it as sensitive and ensure the receiving endpoint logs it appropriately and discards it promptly after use. Mature outbound integration architectures replace session id-based auth with OAuth or named credentials at the endpoint side; this is one of several reasons Flow HTTP Callout is the strategic direction.
Operating, monitoring, and migrating Workflow Outbound Messages
Building a Workflow Outbound Message in 2026 is mostly a migration task; new outbound integrations should use Flow HTTP Callout instead. For existing Outbound Messages still in production, the four-step routine covers: audit existing configurations, monitor the delivery queue, plan migration to Flow, and decommission the Workflow Rule once the Flow has been stable in production. This guide covers the migration path; for the rare cases that still need a new Outbound Message, the configuration steps follow the same pattern.
- Audit existing Workflow Outbound Messages
From Setup, search Outbound Messages. List every active Outbound Message: the source object, the endpoint URL, the field set, the firing Workflow Rule. For each, identify the receiving external system and confirm it is still consuming the messages. Some legacy Outbound Messages fire into endpoints that have been decommissioned years ago; the platform retries for 24 hours and then drops the message, polluting the delivery queue without delivering any value. Document the inventory in the integration runbook so the migration project has a clear scope.
- Monitor the delivery queue weekly
Open Setup, Outbound Messages Delivery Status. Review pending and failed messages. For each non-trivial backlog, identify the cause: endpoint downtime, schema mismatch, authentication failure, network issue. Route the alert to the integration owner. For one-off failures, manually re-queue after fixing the cause. For chronic failures, investigate whether the endpoint is still alive and whether the Outbound Message should be migrated or retired. Mature integration teams add a dashboard widget tracking the failure rate over time; rising failure rates often precede outright endpoint death.
- Plan migration to Flow HTTP Callout
For each Outbound Message that still has business value, plan the migration to Flow. Use the Migrate to Flow tool in Setup to generate a base Flow from the Workflow Rule. The tool produces an Apex Action that mimics the Outbound Message behavior; review the generated Apex Action and refactor it into a native Flow HTTP Callout action with Named Credentials for authentication. Test the new Flow in sandbox against the same endpoint. Communicate the change to the receiving system owner; the SOAP-to-REST switch may require their side to accept the new format too. Document the migration in the change registry.
- Activate the Flow, deactivate the Workflow, monitor
Once the Flow has been stable in sandbox, activate it in production. Watch for the first few messages it fires and confirm the endpoint receives them as expected. After a clean operation window (typically a few days), deactivate the original Workflow Rule. Do not delete the Workflow Rule immediately; keep it inactive for 30 days as a rollback option. After 30 days of clean Flow operation, delete the Workflow Rule and remove the underlying Outbound Message configuration. Document the migration completion in the integration runbook.
- Workflow Outbound Messages are deprecated. Salesforce has not set a hard retirement date, but no new investment goes into the feature; plan migration to Flow HTTP Callout for any business-critical integration.
- Outbound Messages retry for up to 24 hours with exponential backoff. After that, the message is permanently failed. Monitor the delivery queue weekly and triage non-trivial backlogs.
- The receiving endpoint must respond within 10 seconds. Long-running processing on the endpoint side must acknowledge quickly and queue the work; otherwise the platform marks the message as failed and retries.
- Self-signed TLS certificates on the endpoint require explicit Cert Authority registration in Salesforce Setup. Without registration, every message fails with a certificate validation error.
- Session id included in the Outbound Message is a powerful credential. Treat it as sensitive at the endpoint and log it appropriately; better still, migrate to OAuth or named credentials when moving to Flow.
Trust & references
Straight from the source - Salesforce's reference material on Workflow Outbound Message.
- Manage Outbound MessagesSalesforce Help
- Track Outbound MessagesSalesforce Help
- Migrate to FlowSalesforce Help
Hands-on resources to go deeper on Workflow 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 a Workflow Outbound Message?
Q2. What format does it use?
Q3. What's the modern alternative?
Discussion
Loading discussion…