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.