In the rapidly evolving Salesforce ecosystem, integration design is one of the most critical responsibilities of a Salesforce Architect. The platform offers multiple ways to integrate with external systems—each with unique strengths and trade-offs. Among these, Outbound Messages and Platform Events often spark confusion, especially when designing loosely coupled, scalable, and reliable architectures.
Outbound Messages have been around for a long time, serving as a dependable way to push data from Salesforce to external systems through SOAP-based communication. On the other hand, Platform Events represent the modern evolution of Salesforce’s Event-Driven Architecture (EDA)—built for scalability, flexibility, and asynchronous data processing.
So, how do you decide which one to use? This guide dives deep into both mechanisms—explaining their architectures, pros and cons, and key decision factors from an architect’s lens.
- Understanding Salesforce Integration Patterns
- What Is an Outbound Message in Salesforce?
- Architecture of Salesforce Outbound Message
- Security Model of Outbound Messages
- What Are Platform Events in Salesforce?
- Architecture of Salesforce Platform Events
- Security Model of Platform Events
- When to Use Outbound Message
- When to Use Platform Event
- Best Practices for Salesforce Architects
- Integration Patterns from an Architect’s Perspective
- Summary
- References
- Related Posts
Understanding Salesforce Integration Patterns
Salesforce supports a rich ecosystem of integration patterns, broadly categorized into synchronous and asynchronous communication models. Outbound Messages and Platform Events both fall into the asynchronous category, meaning they don’t block user interactions while waiting for responses from external systems.
In simple terms, asynchronous integrations allow Salesforce to send or receive data “in the background.” This is crucial in large-scale enterprise systems where latency and availability can vary.
For architects, the choice between Outbound Messages and Platform Events often depends on the integration pattern you’re implementing:
- Request-Reply: Real-time synchronous data exchange (e.g., REST API).
- Fire-and-Forget: One-way data push without waiting for a response (Outbound Message).
- Event-Driven Messaging: Publish-subscribe model for decoupled systems (Platform Event).
Understanding these distinctions helps align system design with business and technical requirements.
What Is an Outbound Message in Salesforce?
An Outbound Message (OM) is one of the oldest and simplest integration tools in Salesforce. It allows Salesforce to automatically send data to an external system when a record meets specific conditions defined in a Workflow Rule, Approval Process, or Flow.
When the defined trigger fires, Salesforce sends a SOAP message containing the record data (in XML format) to a designated external endpoint. The external system must have a web service listener capable of receiving and processing the message.
Key Characteristics of Outbound Messages:
- No Code Required: Can be configured declaratively within Salesforce setup.
- SOAP Protocol: Communicates via XML-based SOAP envelopes.
- Asynchronous Delivery: Salesforce queues and retries messages if delivery fails.
- Reliable Retry: It retries for up to 24 hours with exponential backoff.
Architecture of Salesforce Outbound Message
When an Outbound Message is triggered, Salesforce constructs an XML payload based on the fields configured in the message definition. This XML is wrapped inside a SOAP envelope and sent to the endpoint defined by the architect.
If Salesforce doesn’t receive an acknowledgment, it retries sending the message using a backoff algorithm for up to 24 hours.
Architecturally, this model works best when integrating with SOAP-capable systems. However, the limitations of SOAP and synchronous acknowledgement make it less ideal for loosely coupled, distributed applications.
Security Model of Outbound Messages
When designing integrations, architects must ensure that every data exchange complies with enterprise-grade security and governance standards. Outbound Messages, while simple, offer several layers of security to safeguard data in transit.
1. Authentication Options
Outbound Messages typically authenticate the connection via basic authentication (username and password) or mutual TLS (certificate-based). The receiving system can validate the source using the Salesforce organization’s IP range or digital certificate. Architects can also enhance security by enforcing HTTPS endpoints and requiring SSL certificates.
2. Firewall and Network Considerations
Since Salesforce operates on the public cloud, external endpoints must be exposed to receive messages from Salesforce IP ranges. For corporate firewalls, architects need to whitelist Salesforce IPs or use secure intermediaries like MuleSoft, Heroku, or AWS API Gateway to manage traffic safely.
3. Retry Logic and Error Handling
Salesforce retries failed Outbound Messages for up to 24 hours, using exponential backoff. If all attempts fail, the message is logged in the Outbound Message Delivery Failure report. Architects should design idempotent endpoints to prevent duplicate processing when retries occur.
4. Compliance Considerations:
For industries with strict compliance (e.g., healthcare, finance), the SOAP protocol’s structured XML schema provides predictable, auditable data exchange. However, Outbound Messages lack fine-grained event control, making them less adaptable to modern event governance.
Outbound Messages are reliable for controlled, stateful communication but not suitable for complex multi-consumer event ecosystems.
What Are Platform Events in Salesforce?
Platform Events represent Salesforce’s modern event-driven messaging mechanism — designed for decoupled, scalable, and reactive system architectures. They form a critical part of Salesforce’s Enterprise Messaging Platform, enabling systems inside and outside Salesforce to communicate asynchronously.
A Platform Event acts like a custom message object that can be published and subscribed to by multiple systems simultaneously. Events are stored temporarily on Salesforce’s Event Bus, which guarantees message delivery to all active subscribers.
Key Characteristics of Platform Events:
- Publish/Subscribe Model: Multiple systems can react to the same event in parallel.
- Event Bus Storage: Events are stored temporarily (retained for 72 hours by default).
- Delivery Mechanism: Uses CometD (Streaming API) or EMP Connector for external consumption.
- Schema-Based Definition: Each event has defined fields (similar to a custom object).
- Support for Replay IDs: Subscribers can replay missed events.
Platform Events are designed for modern, loosely coupled architectures, allowing event producers and consumers to evolve independently—a principle that’s vital for large-scale enterprise ecosystems.
Architecture of Salesforce Platform Events
The architecture of Salesforce Platform Events is built on an event-driven integration model that enables scalable, asynchronous, and loosely coupled communication across enterprise systems. At the core of this model is the Salesforce Event Bus—a high-throughput, multi-tenant messaging backbone that temporarily stores published events and routes them to all active subscribers.
Each Platform Event is defined as a schema-based message object, similar to a custom object, and can be published either internally through Apex, Flows, or Process Builder, or externally via REST API. Once published, every event receives a unique Replay ID and remains available for 72 hours, ensuring reliable delivery and enabling subscribers to replay missed events.
The Event Bus supports both standard and high-volume Platform Events, making it ideal for handling everything from simple business notifications to millions of messages per day in large-scale, enterprise-grade integrations.
Consumers of Platform Events can operate within Salesforce or externally through connected platforms. Internal subscribers — like Apex Triggers, Flows, or Orchestrations — process events in near real time, while external subscribers connect via the Streaming API using CometD (Bayeux protocol) or Salesforce’s EMP Connector.
Each subscriber maintains its own replay pointer, providing resilience and independent fault recovery. This publish–subscribe architecture allows Salesforce to integrate seamlessly with modern event meshes such as MuleSoft, Apache Kafka, or AWS EventBridge, ensuring real-time, bidirectional communication across cloud and on-prem systems.
Security Model of Platform Events
The Security Model of Salesforce Platform Events is designed with enterprise-grade protection to ensure secure, compliant, and controlled event-based communication between Salesforce and external systems. All Platform Event communications are governed by Salesforce’s robust API security framework, which enforces authentication, authorization, and encryption at every layer.
- When external systems publish or subscribe to Platform Events, they must connect through OAuth 2.0 using a Connected App, ensuring that only authorized integrations can access the Event Bus.
- Data transmitted over the Streaming API or CometD protocol is always protected via TLS/HTTPS encryption, safeguarding payloads in transit.
- Salesforce supports field-level security and profile-based permissions that determine who within the organisation can define, publish, or subscribe to specific Platform Events. Architects can also use Event Bus permissions and transaction security policies to monitor or restrict event activity at a granular level.
From a governance and compliance perspective, Platform Events are fully aligned with Salesforce’s trust framework, supporting auditability, tenant isolation, and data retention policies.
Each event is temporarily stored in the Event Bus (typically for 72 hours) and cannot be modified once published, ensuring message immutability and traceability — both essential for industries like finance, healthcare, and government. Architects should integrate Event Monitoring and Shield Encryption where sensitive data is involved, ensuring that event payloads comply with enterprise data protection requirements. In hybrid or multi-cloud setups, Salesforce recommends placing event consumers behind secure gateways such as MuleSoft API Manager or AWS PrivateLink, adding an extra perimeter of defense.
Overall, the Platform Events security architecture combines API-level access control, end-to-end encryption, and governance features to deliver a trusted, compliant, and auditable messaging layer for modern event-driven Salesforce integrations.
Comparison Table: Outbound Message vs Platform Event
| Feature | Outbound Message | Platform Event |
|---|---|---|
| Communication Type | SOAP-based (XML) | Publish-Subscribe (Event Bus) |
| Delivery Mode | Point-to-Point | Multi-Subscriber |
| Protocol | SOAP over HTTPS | CometD (Streaming API), REST |
| Retry Mechanism | 24-hour automatic retries | Replay via Replay ID |
| Payload Format | XML | JSON |
| Delivery Guarantee | Guaranteed with retry | At-least-once delivery |
| Setup Complexity | Low (Declarative) | Moderate (Schema + Subscriber Setup) |
| Best Use Case | Legacy or SOAP-based systems | Event-driven microservices architecture |
| Security | Basic or Certificate Authentication | OAuth / Connected App Integration |
| Scalability | Limited | Highly Scalable |
| Retention | None (immediate delivery) | 72 hours on Event Bus |
| Consumers | Single endpoint | Multiple subscribers |
| Integration Pattern | Fire-and-Forget | Publish-Subscribe / Event-Driven |
When to Use Outbound Message
Outbound Messages are best suited for simple, declarative integrations where the external system supports SOAP and the integration pattern is point-to-point.
Ideal Scenarios:
- Legacy System Integration: When external systems (like SAP, Oracle, or IBM) only accept SOAP messages.
- Low Volume, High Reliability: Small-scale integrations requiring guaranteed delivery with retries.
- No Middleware Involvement: Direct system-to-system communication where middleware is not available.
- Regulatory Environments: Where strict XML schema enforcement is required.
Advantages:
- Easy to configure (no coding).
- Reliable delivery with retry logic.
- Supports synchronous acknowledgment for guaranteed receipt.
Limitations:
- SOAP-only (not REST-friendly).
- Single consumer (not suitable for multi-subscriber scenarios).
- Limited scalability and flexibility for future integrations.
- Harder to integrate with cloud-native event platforms like Kafka or AWS EventBridge.
When to Use Platform Event
Platform Events shine in event-driven, distributed system architectures where decoupling and scalability are critical. As a Salesforce Architect, you’ll find Platform Events indispensable when building solutions that require multiple systems to respond to a single business event in real-time — without hardcoding dependencies between producers and consumers.
Ideal Scenarios:
- Microservice Architectures: When different services (Salesforce, ERP, Marketing Cloud, AWS Lambda, etc.) need to react to the same event asynchronously.
- Real-Time Integrations: When events like “Order Created,” “Payment Processed,” or “Case Escalated” should trigger instant downstream actions.
- Multi-Consumer Systems: When several systems or teams require the same event data without overloading Salesforce with duplicate logic.
- Scalable Event Bus Requirement: When systems demand a loosely coupled, scalable, and resilient messaging backbone.
Advantages:
- Enables Publish-Subscribe model — multiple consumers can act on one event.
- Highly scalable and resilient via Salesforce Event Bus.
- Compatible with Streaming API, EMP Connector, Change Data Capture (CDC), and External Services.
- Flexible payloads and JSON format make it easy to integrate with modern cloud ecosystems.
- Supports Replay ID, ensuring subscribers can retrieve missed events during downtime.
Limitations:
- Requires more setup (defining event schema, managing subscriptions).
- Event retention limited to 72 hours — missed events beyond that are lost.
- Does not guarantee message order if multiple events are published concurrently.
- Requires external systems to maintain replay pointers for guaranteed consumption.
Best Practices for Salesforce Architects
When designing integrations with Outbound Messages and Platform Events, architects must go beyond simple functionality and consider aspects like governance, scalability, observability, and security. The choice between the two should always be rooted in an enterprise’s integration strategy and architectural vision.
1. Design for Loose Coupling
The key to sustainable architecture is decoupling systems wherever possible. Platform Events naturally encourage this by allowing multiple consumers to subscribe independently without impacting each other. In contrast, Outbound Messages create tight coupling — each integration requires direct endpoint configuration.
As a rule of thumb:
- Use Platform Events when you expect to add more consumers in the future.
- Use Outbound Messages when the integration scope is fixed and simple.
2. Implement Idempotent Endpoints
Whether using SOAP or event streaming, ensure that your endpoints can handle duplicate messages gracefully. Outbound Messages may resend data due to retries, while Platform Events can replay the same event multiple times during reconnection.
To prevent data duplication or corruption:
- Include unique identifiers in payloads (e.g., record IDs or event GUIDs).
- Check if a message or event has already been processed before inserting or updating records.
3. Apply Security and Compliance Controls
Security should never be an afterthought. For both integration methods:
- Enforce HTTPS/TLS to secure data in transit.
- Limit exposure by using API Gateways or middleware (e.g., MuleSoft, AWS API Gateway).
- For Platform Events, use Connected Apps and OAuth flows for authentication.
- Audit message flow via Event Monitoring or Transaction Security Policies.
For compliance-heavy industries (HIPAA, GDPR, SOX), always log and store message transactions for auditability.
4. Optimize for Scalability and Throughput
Outbound Messages can struggle under high loads. If the business expects significant growth, Platform Events are the better investment. To optimize performance:
- Use High-Volume Platform Events (HVPE) for large-scale, real-time processing.
- Offload data transformation and enrichment to middleware.
- Use Publish After Commit to ensure events fire only after successful DML operations.
Architecturally, this reduces integration bottlenecks and ensures Salesforce remains performant under heavy event traffic.
5. Monitor and Govern Integrations
Visibility is essential for enterprise reliability.
- For Outbound Messages, use Salesforce’s Delivery Status and Failure Reports.
- For Platform Events, monitor Event Bus metrics, Replay IDs, and Subscription Durability.
- Implement centralized logging in middleware (e.g., Splunk, ELK, or Datadog) to track message flow and failures across systems.
A strong monitoring strategy helps detect message failures early and ensures timely resolution.
6. Build a Decision Framework
Architects should maintain a decision matrix to standardize the integration choice across teams. Here’s a simplified version:
| Criterion | Outbound Message | Platform Event |
|---|---|---|
| Integration Complexity | Low | Medium to High |
| Consumer Count | Single | Multiple |
| Volume | Low to Medium | Medium to High |
| Real-Time Delivery | Yes | Yes |
| Message Retention | None | 72 Hours |
| Protocol | SOAP | CometD / REST |
| Governance Overhead | Low | Moderate |
| Scalability | Limited | High |
| Future-Proof | No | Yes |
This table helps ensure design consistency across multiple projects within a Salesforce ecosystem.
7. Combine Patterns Where Necessary
In many enterprise environments, architects use both Outbound Messages and Platform Events together. For example:
- An Outbound Message might notify a middleware layer.
- The middleware, in turn, publishes a Platform Event to notify multiple subscribers downstream.
This hybrid approach helps bridge legacy systems with modern cloud-native applications, providing a gradual migration path without disrupting existing processes.
Integration Patterns from an Architect’s Perspective
When designing with Salesforce, choosing the right integration pattern ensures scalability, maintainability, and fault tolerance. Here’s how both technologies align with core architectural patterns:
| Integration Pattern | Outbound Message | Platform Event |
|---|---|---|
| Fire-and-Forget | ✅ Supported | ✅ Supported |
| Request-Reply | ❌ Not Supported | ❌ Not Supported |
| Publish-Subscribe | ❌ Not Supported | ✅ Supported |
| Batch Data Synchronization | ❌ Limited | ✅ High-volume support |
| Event-Driven Messaging | ❌ Limited | ✅ Core pattern |
| Real-Time Integration | ✅ | ✅ |
| Guaranteed Delivery | ✅ 24-hour retries | ✅ Replay ID-based |
| Multiple Consumers | ❌ Single consumer | ✅ Multiple consumers |
Architectural Takeaway:
If the solution demands a single target, minimal setup, and SOAP compatibility — Outbound Message works. But if the goal is loose coupling, multi-subscriber architecture, and modern cloud event flow, Platform Events are the clear winner.
Summary
For Salesforce Architects, the decision between Outbound Message and Platform Event isn’t about which is “better” — it’s about choosing the right fit for the integration strategy, system maturity, and scalability needs.
- Outbound Messages are simple, reliable, and ideal for point-to-point SOAP-based integrations with legacy systems. They’re declarative, easy to maintain, and provide guaranteed delivery through Salesforce’s retry mechanism.
- Platform Events, however, represent the future of Salesforce integration. They’re designed for event-driven, loosely coupled, multi-subscriber architectures that support high scalability and modern cloud ecosystems.
An architect’s decision should balance immediate business requirements with long-term flexibility. If your enterprise roadmap involves microservices, real-time analytics, or API-driven ecosystems, Platform Events are the strategic choice. For simpler workflows or legacy ERP integrations, Outbound Messages continue to serve as a dependable tool.
In essence, Salesforce Architects must think beyond the integration — focusing instead on system evolution, governance, and sustainable architecture.
References
Related Posts
- Ultimate Guide to Monitoring Platform Events using Streaming Monitor
- Publish Platform Events from ASP.NET
- How to Correctly Publish Platform Event Using Salesforce Apex
- Efficient Ways to Debug Salesforce Platform Events
- Enhance Salesforce File Security with FileEvent
- Top Salesforce Integration Challenges and How to Solve Them
- How to Set Up Single Sign-On (SSO) Between Okta and Salesforce
- Salesforce Architect Guide to Mastering APIs for Scalable Integration
