- Outbound Messaging: how it works, its SOAP delivery model, and its guaranteed delivery semantics
- Platform Events as an outbound notification mechanism — and when it's better than Outbound Messaging
- The Streaming API (PushTopic and Generic Streaming): the legacy mechanism and its deprecation path
- Delivery guarantees compared: at-least-once, at-most-once, and the durable subscription model
- Configuration complexity compared — who can configure each mechanism
- The decision framework: which mechanism for which scenario
Outbound Messaging: The Original Push Mechanism
Outbound Messaging is Salesforce's oldest push notification mechanism, introduced in the early Salesforce platform era. When a record is created or updated and matches a workflow rule or flow criteria, Salesforce sends an XML SOAP message to a configured endpoint URL. The external system receives the SOAP message, processes it, and must acknowledge receipt by returning a SOAP acknowledgment response. Until the acknowledgment is received, Salesforce retries delivery — this is the guaranteed delivery guarantee of Outbound Messaging.
The retry mechanism is significant: Salesforce retries unacknowledged Outbound Messages for up to 24 hours with exponential backoff. This means if the external endpoint is unavailable for a few hours, it will receive the notifications when it comes back online — as long as it comes back within 24 hours. After 24 hours, undelivered messages are discarded. This at-least-once delivery semantic (with the 24-hour window) is stronger than Platform Events' guarantee for external subscribers.
Outbound Messaging's limitation is its SOAP payload model. The message is a fixed XML format defined by Salesforce, containing the record's selected fields. The external system must parse Salesforce's proprietary SOAP envelope format. There is no flexibility in the message format — you cannot add custom metadata, correlation IDs, or transformed field values. The receiving endpoint must speak SOAP and return the specific Salesforce acknowledgment format.
Platform Events as an Outbound Mechanism
Platform Events, introduced in 2017, are the modern alternative to both Outbound Messaging (for external notification) and PushTopic Streaming API (for external subscriptions). When a Platform Event is published from Apex, Flow, or an external system via REST, it is delivered to all subscribers — both internal (Apex triggers, Flows) and external (systems subscribing via the Pub/Sub API or CometD).
Platform Events provide a more flexible outbound notification than Outbound Messaging. The event payload is developer-defined: you specify exactly which fields are included, can add derived or transformed values, include correlation IDs, and control the event schema independently of the triggering object's schema. The external subscriber receives a clean event format (JSON via CometD or Avro via Pub/Sub API) rather than Salesforce's proprietary SOAP envelope.
The delivery semantic for Platform Events to external subscribers is at-least-once delivery with a 72-hour retention window. The external subscriber must track its replay position (the ReplayId) and resume from the last processed event after downtime. If the subscriber is down for more than 72 hours, events are lost — there is no 24-hour retry guarantee to a specific endpoint like Outbound Messaging provides. Platform Events trade the push retry model for a pull-subscription model.
// Apex publishing a Platform Event for external consumption
// Define the event payload with exactly the fields the consumer needs
Order_Completed__e completedEvent = new Order_Completed__e(
Order_External_ID__c = order.External_Order_ID__c,
Customer_ID__c = order.Account.External_SAP_ID__c,
Total_Amount__c = order.TotalAmount,
Currency_Code__c = order.CurrencyIsoCode,
Completion_Timestamp__c = DateTime.now(),
Correlation_ID__c = UUID.randomUUID() // custom tracking ID
);
EventBus.publish(completedEvent);
// External subscriber receives this clean JSON payload
// — not a raw Salesforce record dump
Streaming API: The Legacy Mechanism
The Streaming API (PushTopic-based) was introduced in 2011 as Salesforce's first real-time notification capability for external consumers. PushTopics define a SOQL query against a Salesforce object, and whenever a record matching the query changes, the change notification is pushed to subscribed clients. External clients subscribe via CometD long-polling.
PushTopics are in maintenance mode and on a deprecation path. Salesforce has officially recommended migrating PushTopic-based integrations to Change Data Capture (for object change notifications) or Platform Events (for custom event-driven patterns). New integrations should never use PushTopics. The Streaming API infrastructure will continue to work for existing integrations for the foreseeable future, but no new features are being added, and the capability may be retired in a future major release.
Generic Streaming events (non-PushTopic streaming) use a StreamingChannel object to push arbitrary JSON payloads to subscribed CometD clients. This was an early attempt at a general-purpose event mechanism before Platform Events existed. It should also not be used for new implementations — Platform Events provide a superior model with better limits, Avro support via Pub/Sub API, and active development investment.
Delivery Guarantee Comparison
Understanding delivery guarantees is critical for choosing the right mechanism for a given scenario. Outbound Messaging provides push-with-retry: Salesforce actively pushes the message to the endpoint and retries for up to 24 hours until the endpoint acknowledges. The external system does not need to maintain a subscription connection — it simply needs to be available on a webhook URL when the message arrives (within the 24-hour window). This is the closest to guaranteed delivery that Salesforce natively provides for external systems.
Platform Events provide durable at-least-once delivery with a 72-hour retention window. The external subscriber maintains a persistent subscription (CometD or gRPC/Pub/Sub API), tracks its ReplayId, and pulls events from the bus. If the subscriber is available, it receives events with very low latency (seconds). If the subscriber is down, it can catch up within the 72-hour window. Events are not actively pushed to the subscriber endpoint — the subscriber must pull them.
Streaming API (PushTopics) provides best-effort delivery. If the subscriber is not connected when a matching record changes, the event is not buffered for later delivery (unlike Platform Events). This makes PushTopics unsuitable for any integration that requires events to be delivered even if the subscriber has brief downtime.
The Decision Framework
Choose Outbound Messaging when: the external system is a legacy endpoint that speaks SOAP, the integration team cannot maintain a persistent subscription connection, delivery guarantee with active retry to a specific endpoint is required, and no developer is available to write Apex (purely declarative configuration is needed).
Choose Platform Events when: a custom payload schema is needed, the event represents a business process (not just a record change), the external consumer needs to subscribe alongside internal Apex/Flow consumers on the same event, multiple consumers need to receive the same event, or the consumer is a modern system that supports gRPC or CometD subscription. This is the correct default for new external notification integrations.
Choose Change Data Capture when: the integration needs to react to any data change on a Salesforce object (creates, updates, deletes, undeletes) without explicit event publishing logic, the consumer needs changed field values (not the full record), and the consumer can maintain a persistent subscription.
Never choose PushTopic Streaming API for new implementations. Migrate existing PushTopic integrations to CDC or Platform Events on the next available maintenance window.
Key Takeaways
- Outbound Messaging provides push-with-retry delivery to a SOAP endpoint — Salesforce retries for 24 hours. It is declarative (no Apex), the oldest mechanism, and constrained to SOAP format with Salesforce's fixed message structure.
- Platform Events provide durable, at-least-once delivery via a subscription model (CometD or Pub/Sub API) with 72-hour retention. The subscriber maintains the connection and tracks ReplayId. Flexible payload schema, developer-defined.
- PushTopic Streaming API is deprecated — provides best-effort delivery with no buffering for offline subscribers. Do not use for new implementations.
- Platform Events are the recommended default for new outbound notification integrations. Outbound Messaging is appropriate only for legacy SOAP endpoints or purely declarative (no-Apex) scenarios.
- At-least-once delivery means both Outbound Messaging and Platform Events can deliver duplicates. Design consumer endpoints to be idempotent — using a correlation ID or event ID to detect and skip already-processed events.
- Change Data Capture is the correct mechanism for "notify on any data change" patterns — it does not require explicit event publishing logic and captures creates, updates, deletes, and undeletes.
Test Your Understanding
1. A legacy order management system (SOAP-based, cannot be modified) needs to receive a notification when a Salesforce Opportunity closes. The operations team must configure the integration without developer assistance. Which mechanism is most appropriate?
2. An external event processing system subscribes to Platform Events. The system goes offline for maintenance for 5 hours and reconnects. With correct ReplayId tracking, what events does it receive?
3. An Outbound Message is sent to an external endpoint. The endpoint processes the message successfully but its HTTP connection to Salesforce times out before returning the SOAP acknowledgment. What happens next?
Discussion & Feedback