If you ever tried to integrate Salesforce with an external system and ended up in a rabbit hole of APIs, middleware, and governor limits? You’re not alone. Integration is where the real complexity begins. But it’s also where architecture becomes art.
In today’s hyperconnected world, Salesforce isn’t just a CRM, it’s the nucleus of enterprise transformation. But here’s the hard truth: even the most powerful Salesforce org will fail to deliver value if its integrations are brittle, outdated, or poorly designed. In this post, I’ll walk you through the essential Salesforce integration design patterns backed by real-world use cases, code examples, and guidance on when to use what. Whether you’re a developer building APIs or a leader shaping architecture strategy, this is your playbook. You can turn tangled spaghetti into elegant, scalable systems with the right design patterns. Let’s break down some of the most powerful (and often overlooked) Salesforce Integration Design Patterns that every Developer, Architect, and Business Leader should know:
1. Remote Call-In (Synchronous)
External System Calls Salesforce via REST/SOAP
Use Case: A partner portal calls Salesforce to get customer credit limits in real time before placing an order.
Example: Apex REST API
@RestResource(urlMapping='/customer/credit/*')
global with sharing class CreditAPI {
@HttpGet
global static String getCreditLimit() {
String customerId = RestContext.request.params.get('id');
Account acc = [SELECT Credit_Limit__c FROM Account WHERE Id = :customerId LIMIT 1];
return String.valueOf(acc.Credit_Limit__c);
}
}When to use:
- External systems need an immediate response from Salesforce.
- Real-time decision-making is required.
- Lightweight data fetch or write.
Use Cases:
- A partner portal fetches customer credit limits from Salesforce before approving financing.
- A mobile app creates a case directly via REST API when a user submits a support form.
- An external system updates a lead status immediately after call disposition.
Considerations:
- Subject to governor limits.
- Higher risk of timeout for heavy processing.
- Use caching or rate limiting externally to protect performance.
2. Remote Process Invocation (Asynchronous)
External System Triggers Salesforce Logic via Events or Queues
Use Case: IoT device sends sensor data to Salesforce; Salesforce triggers maintenance case creation.
Example: Platform Event
// Define a Platform Event: Sensor_Data__e (fields: Temperature__c, Device_Id__c)
trigger SensorTrigger on Sensor_Data__e (after insert) {
for (Sensor_Data__e event : Trigger.new) {
if (event.Temperature__c > 100) {
Case c = new Case(
Subject = 'Overheat Alert for Device ' + event.Device_Id__c,
Status = 'New'
);
insert c;
}
}
}When to Use:
- You need to decouple systems but still trigger business logic in Salesforce.
- You want to offload real-time pressure.
- Ideal for high-throughput, low-latency operations.
Use Cases:
- An IoT platform streams temperature data to Salesforce → Platform Event triggers a Case if threshold breached.
- An eCommerce checkout sends order data to Salesforce via a Platform Event for fulfillment logging.
- A third-party logistics system sends delivery status updates to Salesforce via Apex @future call or Queueable job.
Considerations:
- Platform Events are durable, but only retained for 72 hours.
- You must manage replay IDs and idempotency.
3. Outbound Messaging (Legacy SOAP)
Declarative Push to External System on Record Change
Use Case: When a high-value opportunity is closed-won, notify ERP to initiate billing setup.
How to:
- Create an Outbound Message in a Workflow Rule.
- Endpoint: Your ERP system’s SOAP listener.
- Auto-retry logic built-in by Salesforce.
When to Use:
- You need a no-code integration to push simple data to external SOAP endpoints.
- You want automatic retries on delivery failure.
- The external system can expose a compliant SOAP listener.
Use Cases:
- Send closed-won Opportunity data to SAP when deal is finalized.
- Notify an HR system when a new Contact is created for onboarding.
- Trigger a contract renewal workflow in an external document management tool.
Considerations:
- No support for REST.
- Error handling is limited.
- Slower adoption in modern APIs—consider replacing with Platform Events or Outbound Flows + HTTP Callout.
4. Batch Data Synchronization (ETL/ELT Tools)
Scheduled Bulk Syncs for Data Warehousing, Reporting, Legacy Systems
Use Case: Nightly sync of Salesforce Opportunities to a data warehouse for BI reporting.
Design Tips:
- Handle pagination, retries, and partial failures.
- Respect API call limits (use Bulk API 2.0 for large volumes).
- Add LastModifiedDate filter to extract only changed records.
When to Use:
- Large volume data exchange.
- Nightly or hourly syncs with DWH, legacy systems.
- Read-heavy or write-heavy systems like BI, Reporting, ML Models.
Use Cases:
- Sync all Opportunities from Salesforce to a Snowflake or BigQuery data lake every night.
- Pull Product pricing updates from an ERP into Salesforce once every hour.
- Push Marketing Campaign metrics to Salesforce once the run is complete.
Considerations:
- Handle data skew, partial failures, retries.
- Use Bulk API 2.0 for high-volume writes.
- Always use incremental extracts (LastModifiedDate or Delta).
5. Event-Driven Architecture
Salesforce Publishes Events → Subscribed Systems React
Use Case: When a case status changes to “Escalated,” notify Slack and log it in a compliance system.
Example: Change Data Capture (CDC) for Case
- Enable CDC on the Case object.
- Subscribe via MuleSoft or external system.
{
"data": {
"changeType": "UPDATE",
"entityName": "Case",
"change": {
"fields": ["Status"]
}
}
}When to Use:
- You need real-time, decoupled, reactive systems.
- Multiple consumers need the same event.
- Your architecture must scale horizontally.
Use Cases:
- A Salesforce Case escalation triggers notifications in Slack, logging in Splunk, and a compliance alert via Kafka—all via the same Platform Event.
- When a Lead is converted, a Platform Event notifies the data warehouse, marketing platform, and compliance system.
- CDC is enabled to track changes to the Account object, syncing updates to an MDM system.
Considerations:
- Replay logic and error handling needed in subscriber systems.
- Events are ephemeral—must be processed quickly.
6. Middleware-Centric Design (Orchestration Layer)
All systems talk through a middleware like MuleSoft
Use Case: Salesforce needs to get order history from SAP but SAP requires token-based auth, data transformation, and retries.
MuleSoft Flow Example (Pseudo):
<flow name="getOrderHistory">
<http:listener config-ref="HTTP_Listener_config" path="/orders/{accountId}" />
<set-variable value="#[attributes.uriParams.accountId]" variableName="accountId"/>
<http:request config-ref="SAP_Config" path="/sap/orders" method="GET">
<headers>
<header name="Authorization" value="#[vars.sapToken]"/>
</headers>
</http:request>
<transform>
<json-to-xml />
</transform>
<set-payload value="#[payload]" />
</flow>Middleware lets you:
- Handle multiple environments
- Cache responses
- Centralize auth and logging
- Avoid tight coupling with Salesforce
When to Use:
- You want a centralized integration layer to decouple Salesforce from downstream systems.
- You need to handle orchestration, security, transformations, and retries.
- You integrate with multiple systems (SAP, Workday, NetSuite, etc.).
Use Cases:
- Salesforce calls MuleSoft to get real-time order history from SAP, which requires transformation and tokenized security.
- A banking system connects to Salesforce via MuleSoft to sync customer financial profiles with audit logging.
- MuleSoft orchestrates data flows between Salesforce, Tableau, and Marketo for a unified customer journey.
Considerations:
- Slightly more latency due to orchestration.
- Cost and governance overhead.
- Requires expert middleware architects.
#Salesforce #IntegrationArchitecture #EventDrivenDesign #PlatformEvents #CDC #MuleSoft #SalesforceArchitect #EnterpriseArchitecture #ScalableSystems #DataIntegration