Salesforce Event-Driven Architecture: Decoupling Orders

In high-volume enterprise environments, synchronous API integrations often become a bottleneck. Salesforce Event-Driven Architecture (EDA) offers a robust alternative to direct REST SOAP calls, specifically when handling mission-critical transaction records like the Order object.

This article details how to architect a decoupled integration pattern that utilizes a Publish/Subscribe model to protect your org from API limits and record-locking contention.

Why Salesforce Event-Driven Architecture Beats API Calls

Traditional integrations tightly couple the source system (e.g., an ERP or Web Store) with Salesforce. If the external system pushes 10,000 orders via the standard REST API, it creates immediate load, risking row locks on the Account or Order tables.

By adopting Salesforce Event-Driven Architecture, you introduce a buffer. Instead of writing directly to the standard Order object, the external system publishes messages to the Event Bus. This allows Salesforce to process incoming data asynchronously, ensuring that a spike in traffic does not degrade system performance or hit concurrent Apex limits.

Designing the Platform Events Integration for Orders

To implement this, you do not use the standard Order object for the initial ingestion. Instead, you define a custom Platform Event, which acts as an ephemeral, virtual object.

Let’s call this definition Order_Creation__e. Unlike a custom object (__c), records in __e are not stored permanently in the database; they exist on the event bus for a retention window (usually 72 hours) to be picked up by a subscriber.

Platform Events Integration shifts the logic from “receive and save” to “listen and process.” The external system simply fires a JSON payload to the event endpoint, receiving an immediate 200 OK without waiting for the complex validation logic of the Order trigger chain to complete.

Mapping JSON Payloads to Order and OrderItem Records

Once the event is published, an Apex Trigger or Platform Event-Triggered Flow subscribes to Order_Creation__e. This is where the transformation happens.

The subscriber logic must parse the event payload and map it to the standard schema:

1. Header Mapping: The Order_Creation__e.Customer_ID__c is used to query the correct Account ID.
2. Line Item generation: The subscriber iterates through the JSON array within the event to instantiate OrderItem records.
3. Commit: The trigger performs a Database.insert for the Order and OrderItem records in a single transaction context.

This separation ensures that if the Platform Events Integration fails due to a validation rule, the external system is not left hanging, the error is handled via an error logging object or a callback event.

Handling Replay IDs in Salesforce Event-Driven Architecture

A critical component of this architecture is durability. Salesforce Event-Driven Architecture utilizes a ReplayId field for every event published.

If the subscription service goes down or the Apex trigger fails to fire, the system tracks the last processed ReplayId. When the service resumes, it can “replay” the stream from that specific checkpoint. This guarantees zero data loss for Order transactions, a level of reliability that is difficult to script manually with standard REST API retry logic.