Salesforce Inbound vs Outbound Integration Patterns: Architecture & Best Practices

In plain words: Think of Inbound Integration as receiving mail into Salesforce (external systems pushing data or Salesforce pulling external data), while Outbound Integration is sending mail out (Salesforce notifying external ERPs, payment gateways, or databases when something happens).

Connecting Salesforce to external enterprise systems requires deciding the direction of data flow and the timing of the exchange. Depending on your business process, integrations operate either as inbound requests entering Salesforce or outbound events dispatched to external platforms.

1. Understanding Inbound Integration Patterns

Inbound integration brings external data or transactions directly into Salesforce. External clients initiate calls into standard or custom Salesforce endpoints, or Salesforce visualizes external records on demand without copying them.

• Salesforce Connect & External Objects: Provides on-demand data virtualization via OData adapters. Records stay in the external database (e.g., SAP or Postgres) and are read in real time inside Salesforce without consuming data storage limits.
• Standard & Custom REST/SOAP APIs: External systems authenticate via OAuth 2.0 and invoke endpoints to execute CRUD operations or run custom Apex services decorated with @RestResource or webservice.
• Web-to-Lead and Web-to-Case: Direct HTTP POST mechanisms that capture prospective leads and customer support tickets from external web forms without requiring authenticated API access.
• Composite & Bulk API 2.0: Optimized for high-throughput data loading. Composite APIs execute multiple dependent operations in a single request, while Bulk API 2.0 processes millions of records asynchronously.

Real-World Example: Inbound Apex REST Web Service
Exposing a custom endpoint for external billing platforms to update invoice statuses:

@RestResource(urlMapping='/v1/Invoices/*')
global with sharing class InvoiceStatusService {
    @HttpPost
    global static String updateInvoiceStatus(String invoiceNumber, String status) {
        Invoice__c inv = [SELECT Id, Status__c FROM Invoice__c WHERE Invoice_Number__c = :invoiceNumber LIMIT 1];
        inv.Status__c = status;
        update inv;
        return 'SUCCESS: ' + inv.Id;
    }
}

2. Exploring Outbound Integration Patterns

Outbound integration triggers when an event inside Salesforce notifies downstream systems, invokes third-party web services, or syncs transactional data with an ERP.

• Platform Events & Event Relays: An event-driven architecture using a publish-subscribe (pub/sub) model. Salesforce publishes structured JSON payloads, which external systems consume via the Pub/Sub API or native AWS EventBridge Event Relays.
• Apex HTTP Callouts: Programmatic requests sent from Apex using HttpRequest and Http classes. Often executed asynchronously using @future(callout=true) or Queueable Apex (Database.AllowsCallouts) to avoid blocking user transactions.
• Flow HTTP Callouts: Low-code outbound integrations configured directly in Flow Builder using Named Credentials and External Services, eliminating the need for custom Apex code.
• Outbound Messaging: Sends SOAP XML notifications when triggered by record actions, featuring automated retry mechanisms for transient network failures.

360 Pattern Architecture Card:

• Data Virtualization (Inbound): Use Salesforce Connect when data freshness is critical and storage conservation is required.
• Event-Driven Asynchronous (Outbound): Use Platform Events with the Pub/Sub API to decouple systems and handle high transaction volumes.
• Point-to-Point Synchronous (Outbound): Use Apex Callouts with Named Credentials for immediate request-reply scenarios (e.g., real-time credit checks).
• High Volume Batch (Inbound): Use Bulk API 2.0 for asynchronous transfers exceeding 10,000 records.

3. Architecture Best Practices & Common Pitfalls

Developer Trap (Governor Limits): Avoid invoking synchronous Apex callouts inside synchronous DML loops. Performing DML operations before an HTTP callout in the same transaction causes the dreaded System.CalloutException: You have uncommitted work pending error. Always structure callouts before DML or use Queueable Apex.

Core Rule: Use event-driven, asynchronous patterns (Platform Events / CDC) for one-way notifications, and use Named Credentials with External Services for secure, low-code point-to-point integrations.

• Secure Endpoints with Named Credentials: Never hardcode authentication headers or tokens. Named Credentials manage OAuth handshakes and URL configurations securely.
• Enforce Idempotency: External systems sending inbound data should provide unique transaction IDs or external IDs to prevent duplicate record creation during network retries.
• Monitor Governor Limits: Track daily API request allocations and platform event publishing limits using the Salesforce Limits API.

Summary

Selecting the right integration pattern depends on data volume, timing requirements, and system coupling. Modern Salesforce architectures favor asynchronous, event-driven designs like Platform Events for outbound communication and REST or Salesforce Connect for inbound operations, delivering reliable, scalable, and secure connectivity across the enterprise.