Salesforce Outbound Messaging: Setup & Modern Alternatives

Outbound Messaging in Salesforce sends a SOAP message to an external endpoint URL whenever a record meets your criteria - a declarative, retry-backed way to push data out of Salesforce without writing Apex. You define an outbound message (the object, the endpoint, the fields to send, and whether to include the session ID), generate a WSDL to build a listening service, then trigger the message from automation.

The catch in 2026: the classic trigger - the Workflow Rule - reached end of support on 31 December 2025, alongside Process Builder. Existing rules still run, but they get no fixes or new features. So new outbound messages should fire from Flow or an approval process, and for genuinely event-driven integrations you should usually reach for Platform Events, Change Data Capture (CDC), or Apex callouts instead. Outbound Messaging stays a fine choice for simple, declarative, guaranteed-delivery hand-offs - but it is legacy SOAP, not the default for new builds.

Key takeaways

• What it is: a point-and-click action that POSTs a SOAP notifications envelope to an external HTTPS endpoint when a record changes.
• Guaranteed-ish delivery: your listener must return an Ack of true; if it does not, Salesforce retries with backoff for up to 24 hours.
• You build the listener from a WSDL generated from the outbound message definition; the endpoint must be HTTPS with a valid certificate.
• Trigger options in 2026: Flow (Send Outbound Message core action), approval processes, and entitlement processes. Workflow Rules are end-of-support (31 Dec 2025) - migrate them to Flow.
• For new integrations, prefer Platform Events or Change Data Capture (event-driven, JSON, scalable) or Apex callouts with Named Credentials (REST, full control). Use Outbound Messaging only when declarative + retry is enough.
• "Send session ID" lets the listener call back into Salesforce as the running user - convenient, but a credential you must protect.

What is an outbound message in Salesforce?

An outbound message is an automated action that sends a SOAP message over HTTPS to a designated endpoint URL (your "listener") when the automation that owns it fires. The payload is a notifications element containing one or more Notification records, each wrapping the specific fields you selected when you defined the message, plus org context such as the OrganizationId, the ActionId, and connection URLs.

If you tick "Send Session ID", Salesforce also includes a live SessionId so the listener can call straight back into the API as the user who triggered the action - handy for fetching related data, but treat that token like a password.

Because the contract is SOAP, you do not hand-code the schema. Salesforce generates a WSDL from the outbound message definition; you feed that WSDL to your stack to scaffold a strongly-typed listener that knows exactly which fields to expect.

How does the SOAP notification and retry actually work?

When the message fires, Salesforce POSTs the SOAP envelope to your endpoint and then waits for a response. Your listener must return a SOAP body containing <Ack>true</Ack>. Behaviour from there:

• Ack true -> Salesforce marks the message delivered and drops it from the queue.
• Ack false, an error, a timeout, or a bad certificate -> Salesforce keeps the message queued and retries with increasing intervals for up to 24 hours, after which it is dropped.
• Messages can arrive out of order and the same notification can be delivered more than once, so your listener must be idempotent (key off the Notification Id).

You can watch all of this under Setup -> Outbound Messages (the delivery monitor), which shows next items for delivery, oldest failures, attempt counts, and failure reasons, and lets you retry or delete stuck messages. Here is the shape of a notification Salesforce sends:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <notifications xmlns="http://soap.sforce.com/2005/09/outbound">
      <OrganizationId>00Dxx0000001gPLEAY</OrganizationId>
      <ActionId>04kxx00000004CBAAY</ActionId>
      <!-- present only if "Send Session ID" was enabled -->
      <SessionId>00Dxx0000001gPL!AQ4AQ...redacted...</SessionId>
      <EnterpriseUrl>https://yourorg.my.salesforce.com/services/Soap/c/63.0/00Dxx0000001gPL</EnterpriseUrl>
      <PartnerUrl>https://yourorg.my.salesforce.com/services/Soap/u/63.0/00Dxx0000001gPL</PartnerUrl>
      <Notification>
        <Id>04lxx00000000123EAA</Id>
        <sObject xsi:type="sf:Account"
                 xmlns:sf="urn:sobject.enterprise.soap.sforce.com">
          <sf:Id>001xx000003DGbAAAW</sf:Id>
          <sf:Name>Acme Corp</sf:Name>
          <sf:Industry>Manufacturing</sf:Industry>
        </sObject>
      </Notification>
    </notifications>
  </soapenv:Body>
</soapenv:Envelope>

What does the listener have to send back?

Exactly one thing: a SOAP envelope whose body acknowledges receipt. Salesforce only cares that it can parse Ack and find true. A minimal acknowledgement looks like this, and a tiny Node/JavaScript handler that returns it is shown below - no SOAP framework required, since the contract is fixed.

// Minimal outbound-message listener (Node.js / JavaScript, no TypeScript).
// Salesforce only needs <Ack>true</Ack> back; parse the body asynchronously
// so a slow downstream call never causes a Salesforce timeout + retry storm.
import { createServer } from "node:http";

const ACK =
  '<?xml version="1.0" encoding="UTF-8"?>' +
  '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">' +
  '<soapenv:Body>' +
  '<notifications xmlns="http://soap.sforce.com/2005/09/outbound">' +
  '<Ack>true</Ack>' +
  '</notifications></soapenv:Body></soapenv:Envelope>';

createServer((req, res) => {
  let xml = "";
  req.on("data", (chunk) => (xml += chunk));
  req.on("end", () => {
    // Ack immediately so Salesforce dequeues the message...
    res.writeHead(200, { "Content-Type": "text/xml; charset=utf-8" });
    res.end(ACK);
    // ...then process out-of-band, keyed on the Notification Id (idempotent).
    queueForProcessing(xml).catch(console.error);
  });
}).listen(443); // must be reachable over HTTPS with a valid certificate

How do you set up an outbound message? (step by step)

Defining the message is the same regardless of what triggers it:

1. Go to Setup and search Quick Find for Outbound Messages, then click New Outbound Message.
2. Pick the object (for example, Account or your custom object) and click Next.
3. Enter a Name and Unique Name, the Endpoint URL (your HTTPS listener), and the user to send as (whose permissions the session ID, if sent, will carry).
4. Tick Send Session ID only if your listener needs to call back into Salesforce.
5. Move the fields you want to send into the selected list. Keep this lean - only what the listener actually needs.
6. Save. From the message's detail page, click Click for WSDL to download the WSDL and scaffold/validate your listener against it.

At this point the message exists but nothing fires it yet. That is the part that changed in 2026.

How do you trigger an outbound message in 2026? (Workflow Rules are retiring)

Historically you attached an outbound message to a Workflow Rule. That path is on its way out: Workflow Rules and Process Builder reached end of support on 31 December 2025. Existing rules keep running, but Salesforce will not fix bugs in them or add features, and Salesforce strongly recommends moving automation to Flow (there is a built-in Migrate to Flow tool for this). For background on the old declarative tools, see our notes on the Workflow field update action and on Process Builder in Salesforce.

Your supported ways to trigger an outbound message today:

• Flow (recommended). Since Winter '22, Send Outbound Message is a core action in Flow Builder, usable in record-triggered flows that run after save. You do not pass input parameters - the triggering record's Id is passed implicitly - so you select the same defined outbound message and Flow handles the rest.
• Approval processes. Add New Outbound Message as an action on Submission, Approval, Rejection, or Recall steps. Entitlement processes can fire them too.
• Workflow Rules (legacy). Still functional, but unsupported - do not build new ones; migrate existing ones to Flow.

So the headline for any new requirement: define the outbound message once, then trigger it from a record-triggered Flow (or an approval process), never from a new Workflow Rule.

Outbound Messaging vs Platform Events, CDC, Apex callouts & MuleSoft

Outbound Messaging is one of several ways to get data out of Salesforce, and it is the oldest. For most new event-driven work in 2026 it is not the best fit - the modern, JSON-based, scalable options are event channels (Platform Events, Change Data Capture) or imperative callouts. Use this table to choose:

Mechanism	Code needed	Protocol / format	Direction & model	Delivery	Best for
Outbound Messaging	No (declarative)	SOAP / XML over HTTPS	SF -> external, push on record change	Retry up to 24h, needs Ack	Simple, declarative, guaranteed hand-offs to one endpoint
Platform Events	Low (declarative publish or Apex)	Event bus, JSON-ish	Pub/sub, many subscribers	At-least-once, replay window	Decoupled, event-driven integrations and fan-out
Change Data Capture	No to publish	Event bus, JSON	Auto data-change events, pub/sub	At-least-once, replay window	Streaming record changes (create/update/delete/undelete) to external systems
Apex callout + Named Credentials	Yes (Apex)	REST/SOAP, any format	SF -> external, you control timing	Synchronous or async/queueable; you build retries	Custom REST APIs, transforms, auth handled by Named Credentials
MuleSoft / iPaaS	Config + some code	Any (REST, SOAP, files, DB)	Bi-directional orchestration	Tool-managed retries/queuing	Multi-system orchestration, transformation, governance at scale

Which one should you choose?

• New event-driven integration? Start with Platform Events or Change Data Capture - they are JSON, scale to many subscribers, support replay, and avoid SOAP entirely.
• Need to call a specific REST API, transform data, or control auth? Use an Apex callout with Named Credentials (and Queueable Apex for async/retry).
• Orchestrating several systems with mapping and governance? That is MuleSoft / iPaaS territory.
• Just need a no-code, fire-and-forget push to one endpoint with built-in retry? Outbound Messaging is still a reasonable, low-maintenance choice - just trigger it from Flow, not a Workflow Rule. For the wider menu of options, see our guide to Salesforce integration patterns and third-party apps.

Limits and gotchas to watch

• HTTPS only, valid certificate. A self-signed or expired cert means failed delivery and retries; the endpoint must be publicly reachable.
• No payload transformation. You send the selected fields as SOAP XML, full stop. If the target wants a different shape, you transform on your side (or use an Apex callout / iPaaS).
• Limited error handling. You cannot branch on the listener's business response - only delivery succeeds or retries. Logic lives in your listener.
• Org limits apply to pending outbound messages and per-message field counts; very high-volume change streams are a better fit for CDC.
• Security of the session ID. "Send Session ID" ships a live token; restrict the send-as user's permissions and validate the source on your endpoint.
• Idempotency is on you. Duplicate and out-of-order deliveries happen - dedupe on the Notification Id.

Frequently Asked Questions

Is Outbound Messaging deprecated in Salesforce?

No - outbound messaging itself is not deprecated and continues to work. What is retiring is its most common trigger: Workflow Rules (and Process Builder) reached end of support on 31 December 2025. The outbound message action still exists in Flow, approval processes, and entitlement processes, so you keep the feature but trigger it from a supported tool - ideally a record-triggered Flow.

Can I send an outbound message from a Flow?

Yes. Since the Winter '22 release, Send Outbound Message is a core action in Flow Builder, available in record-triggered flows that run after the record is saved. You do not supply input parameters; the triggering record's Id is passed implicitly. You simply reference an outbound message you already defined under Setup -> Outbound Messages.

What format does an outbound message use?

It is a SOAP message in XML, sent over HTTPS to your endpoint. The body is a notifications element containing your selected fields plus org context (OrganizationId, ActionId, connection URLs, and optionally a SessionId). You generate a WSDL from the message definition to build a listener that matches the schema. This SOAP/XML contract is also why newer, JSON-based options are preferred for fresh integrations.

What happens if my endpoint does not respond?

Salesforce expects your listener to return a SOAP Ack of true. If it gets an error, a timeout, a bad certificate, or false, it keeps the message queued and retries with increasing intervals for up to 24 hours before giving up. You can monitor and manually retry or delete pending messages under Setup -> Outbound Messages.

Outbound Messaging vs Platform Events - which should I use?

For new event-driven integrations, prefer Platform Events (or Change Data Capture for record-change streams): they use a scalable JSON event bus, support many subscribers and replay, and avoid SOAP. Outbound Messaging is best when you want a no-code, single-endpoint push with built-in retry and do not need transformation or fan-out. Choose Apex callouts with Named Credentials when you must call a specific REST API or control timing and auth.

Should I include the session ID in the outbound message?

Only if your listener needs to call back into the Salesforce API as the sending user. The session ID is a live credential, so omit it when the payload fields are enough. If you do send it, scope the send-as user's permissions tightly and validate the request source on your endpoint to limit the blast radius if the token leaks.

Need help modernizing Salesforce automation?

Whether you are migrating Workflow Rules to Flow, replacing brittle outbound messages with Platform Events or Change Data Capture, or building Apex callouts and MuleSoft integrations the right way, our certified team can design and deliver an integration architecture that scales. Explore our Salesforce consulting and development services or get in touch to talk through your org.