Introduction
Integration patterns are repeatable solutions to common integration problems between Salesforce and other systems. Understanding these patterns is essential for architects, developers, and consultants preparing for Salesforce interviews. This guide explains the core integration patterns, when to use each, pros and cons, and brief implementation notes.
Core Integration Patterns
1. Remote Call-In (Synchronous Request)
Description: An external system invokes Salesforce to perform an operation and expects an immediate response. Common when an external web app needs validation, record lookup, or business logic executed inside Salesforce.
When to use: Low-latency requests where immediate confirmation is required (e.g., real-time order validation).
Pros: Real-time, consistent business rules, single source of truth.
Cons: Tightly-coupled, Salesforce availability affects callers, API limits apply.
Implementation: Expose REST or SOAP endpoints (Apex REST controllers, Apex SOAP) or use Platform Events with request-response wrappers. Secure via Named Credentials, OAuth, or JWT.
// Example Apex REST endpoint
@RestResource(urlMapping='/OrderValidate/*')
global with sharing class OrderValidate {
@HttpPost
global static String validate() {
// parse request, apply business rules, return response
return 'OK';
}
}
2. Remote Process Invocation—Request and Reply
Description: Salesforce calls an external service, waits for a response, and continues processing based on that reply.
When to use: When Salesforce needs authoritative data from an external system before proceeding (e.g., credit check during opportunity close).
Pros: Salesforce-driven, synchronous decision-making across systems.
Cons: Blocking callouts consume transaction time and are subject to callout limits and external system SLAs.
Implementation: Use Apex HTTP callouts, External Services, or middleware connectors. Use continuation (for long-running callouts in Lightning) to keep UI responsive.
3. Batch Data Synchronization (Periodic Bulk)
Description: Regular, scheduled synchronization of large data sets between Salesforce and external systems.
When to use: Nightly ETL jobs, data replication for analytics, or bulk imports and exports.
Pros: Efficient for large volumes, reduces real-time coupling.
Cons: Data latency; conflicts need resolution strategies.
Implementation: Use middleware (MuleSoft, Dell Boomi), ETL tools, or Salesforce Data Loader CLI. For inbound bulk, use Bulk API 2.0 or Bulk API with CSV batches.
4. Remote Process Invocation—Fire and Forget (Asynchronous)
Description: Salesforce triggers an external process but does not wait for the response. Useful for offloading work.
When to use: Trigger external provisioning, notifications, or long-running transactions where Salesforce does not need immediate feedback.
Pros: Decouples systems, non-blocking, resilient with queuing.
Cons: No immediate confirmation; requires monitoring and error handling.
Implementation: Use Platform Events, outbound messaging (Workflow), or publish to a message queue via middleware.
5. Data Virtualization / On-Demand Data
Description: Salesforce retrieves data on demand from an external system rather than storing it locally. This pattern is useful when data volume or ownership precludes replication.
When to use: Reference data or large data sets (e.g., product catalogs, external inventory).
Pros: No data duplication, always current data.
Cons: Dependent on external system performance and availability; increased latency on queries.
Implementation: Use External Objects (Salesforce Connect) with OData or custom Apex adapters.
6. UI Integration (Embedded or Connected Experiences)
Description: Integrate external UIs or components into Salesforce UI (or vice versa) for a seamless user experience.
When to use: Add third-party widgets, interactive experiences, or integrate legacy systems into Lightning pages.
Pros: Better UX, reuses existing external interfaces.
Cons: Cross-domain security, embedding complexity, and session management.
Implementation: Use Lightning components with iframes, Canvas Apps, LWC with proxying, or Single Sign-On (SSO) for session management.
7. Event-Driven Integrations (Publish/Subscribe)
Description: Systems communicate via events. Salesforce publishes or subscribes to events; other systems react asynchronously.
When to use: Loose coupling, reactive architectures, near-real-time propagation of changes.
Pros: Highly scalable, resilient, decoupled.
Cons: Complexity in event ordering and eventual consistency challenges.
Implementation: Use Platform Events, Change Data Capture (CDC), and external message brokers (Kafka, AWS SNS/SQS). Use replay and error handling strategies.
Choosing the Right Pattern
Factors to consider:
- Latency requirements (real-time vs. batch)
- Coupling tolerance (tight vs. loose)
- Data ownership and volume
- Security and compliance constraints
- Error handling and transaction management needs
Common Implementation Tips
- Use Named Credentials and Protected Custom Settings for secure credentials and connection management.
- Prefer middleware for orchestration, transformation, and retry logic when multiple systems are involved.
- Design for idempotency in APIs and events to avoid duplicate processing.
- Monitor integration health with error queues, DLQs, and alerting.
- Consider API limits, governor limits, and bulkification in Apex when designing integrations.
Sample Apex Callout (HTTP GET)
Http http = new Http();
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_Named_Credential/some/resource');
req.setMethod('GET');
HttpResponse res = http.send(req);
System.debug(res.getBody());
Conclusion
Mastering integration patterns is critical for building robust enterprise-grade solutions on Salesforce. In interviews, articulate the trade-offs for each pattern, provide implementation examples, and explain how you’d handle security, error recovery, and scaling.