Securing Cross-Platform Data Integrity with Salesforce Integration Patterns and External IDs

In enterprise architecture, the Salesforce instance rarely exists in isolation. It must fluidly exchange data, such as Orders, Customers, and Inventory with ERP systems, data warehouses, and custom applications. The challenge is not merely moving data, but ensuring data integrity and data sovereignty across these disparate systems.

Reliance on custom, brittle API calls and manual lookups leads to transactional failures, data drift, and eventual lack of trust in the CRM. True, resilient integration requires two foundational Salesforce Integration Patterns: a reliable addressing scheme (the External ID) and a resilient transport mechanism (the Platform Event).

The Core of Data Integrity: The External ID Field

When synchronizing data between systems (e.g., NetSuite, SAP, or a custom ledger and Salesforce), relying on the internal 18-character Salesforce Id is a critical design flaw. That ID is internal to the Salesforce instance and will change if the data is migrated.

The External ID field solves this by establishing a non-Salesforce-specific unique identifier.

• Function: It is a custom field marked as “External ID” on standard or custom objects (e.g., Account, Order__c).
• Best Practice: It must map directly to the Primary Key (PK) of the record in the external system (e.g., the Customer_ID from the ERP).
• The Power of UPSERT: The External ID enables the UPSERT (UPDATE or INSERT) operation via the Salesforce API. By passing the External ID in the payload, the platform intelligently checks if a record with that key exists. If it does, it updates; if not, it inserts. This ensures idempotence running the same operation multiple times yields the same correct result.

Maintaining Data Sovereignty

The External ID field allows you to establish which system is the true Source of Truth (SSOT) for a given record. If your ERP is the SSOT for inventory data, the External ID ensures that all updates originate from the ERP’s unique key, maintaining data sovereignty in the ledger system while allowing Salesforce to consume the data reliably.

The Asynchronous Solution: Platform Events

The REST API is synchronous: a request is made, and the system waits for a response. In high-volume environments (e.g., thousands of website orders in minutes), this pattern is prone to API limit exceptions and transaction timeouts.

Modern architecture dictates an event-driven, asynchronous model, and in Salesforce, this is handled by Platform Events.

Publish/Subscribe Architecture

A Platform Event (e.g., ERP_Order_Created__e) is a special object that represents a notification rather than a data record.

• Publishing: An external system can publish an event (via REST, SOAP, or Apex) to the Salesforce Event Bus. This is a fast, near real-time operation that bypasses traditional transaction management limits.
• Subscribing: Internal Salesforce components (like Flows, Apex Triggers, or external middleware like MuleSoft) subscribe to this event. When the event is published, all subscribers are notified simultaneously and can process the data independently.

This decouples the sending system from the receiving system, ensuring reliability even if a subscriber is temporarily down or needs more time to process the data.

Guaranteed Delivery and Transaction Boundaries

Unlike simple REST callbacks which can fail silently, Platform Events offer guaranteed delivery via a resilient event bus. They manage their own transaction boundaries, meaning a failure in a subscriber’s Flow logic will not crash the external system that published the original event. This robust transport mechanism is essential for mission-critical financial integrations.

Implementing Bi-Directional Synchronization

The ultimate goal is often bi-directional sync, where changes in Salesforce (e.g., a Sales Rep updating an Account address) must reflect in the ERP, and vice-versa.

By combining these two patterns, we achieve a robust synchronization architecture:

1. ERP to Salesforce: The ERP publishes a Customer_Update__e Platform Event, containing the External ID (ERP_Customer_ID) and the new data. A subscribing Flow on the Salesforce side catches the event and uses the External ID to execute the UPSERT operation on the Account object.
2. Salesforce to ERP: An Apex Trigger on the Account object detects a change and publishes a new event (SFDC_Customer_Update__e). The ERP’s integration layer subscribes to this event and uses the External ID to update its corresponding record.

This chain of custody, anchored by the External ID and transported by the Platform Event, ensures that data integrity is maintained at scale.