Three Questions That Dictate the Pattern — Not the Tool
A common mistake when choosing a Salesforce integration is starting with the tool: MuleSoft, Platform Events, Bulk API, or a simple Webhook. The tool is a result, not a starting point. Three questions determine the correct pattern:
- How quickly does the other side need to know? A second, a minute, an hour, or a day – this differentiates Real-Time from Batch.
- Who owns the data at any given moment? If the answer isn't unambiguous, no technical pattern will solve the problem.
- What happens when the other side is unavailable? "We'll just try again" isn't an answer – defined behavior is needed: Retry, a queue, or explicit failure.
Anyone who answers these three questions before selecting a technology will almost always arrive at the same conclusion an experienced architect would – but without paying for trial and error in production. More on the connection between this decision and the overall architecture can be found in our CRM Architecture Guide.
The Pattern Map: When Each Is Appropriate
| Pattern | Typical Response Time | Typical Use Case | Maintenance Cost | Primary Risk |
|---|---|---|---|---|
| Synchronous Request-Reply | Milliseconds to Seconds | Credit check before transaction approval on screen | Medium | Timeout blocks the user |
| Fire-and-Forget | Immediate upon sending, no waiting for results | Sending an event to create a Task in another system | Low-Medium | Silent failure without monitoring |
| Periodic Batch | Hours to a day | Product catalog synchronization once a day from ERP | Low | Time gaps between systems |
| CDC (Change Data Capture) | Seconds to Minutes | Order status update affecting support | Medium-High | Event Bus overload with multiple changes |
| Event-Driven (Platform Events / Pub-Sub) | Seconds | Notification of a business event to multiple consumers simultaneously | High during setup, low during maintenance | Requires Schema and Versioning discipline |
This table is a starting point for discussion, not a final verdict. A single system can, and sometimes must, use several patterns simultaneously based on the data type.
Why Latency Isn't Enough to Decide
The second common mistake: deciding based solely on Latency and ignoring Consistency. A fast pattern that updates only one side, leaving the other "almost synchronized," creates a more severe problem than a slower but consistent pattern – because users learn not to trust the data, and then bypass the system.
The correct question is a dual one: how quickly is a response required, and how critical is a situation where the two sides are momentarily out of sync. A pricing process presented to a customer demands both speed and full consistency – here, a synchronous Request-Reply with a defined Timeout and explicit error handling is necessary. Updating "article views" can comfortably tolerate a delay of minutes – there, Fire-and-Forget or CDC suffice.
Data Ownership: A Decision Preceding Any Pattern
Before deciding how data flows between systems, it's crucial to determine where it is "authoritative." A field updated in two systems without a defined owner creates a synchronization loop: A sends to B, B updates and broadcasts back to A, A sends again. This isn't an edge case – it's the expected result of bi-directional synchronization without a clear rule.
A practical working rule: for every shared field, assign a single Owner. If there's a genuine business need for editing from both sides (e.g., customer service updates an address in both Salesforce and ERP), add an explicit Conflict Resolution rule – last timestamp wins, or one field dictates while the other is for display only. Managing permissions around these sensitive fields is discussed in the Salesforce Permission Model Guide.
Error Handling: The Test Most Projects Skip
Almost every integration undergoes Happy Path testing. Few undergo systematic testing of these three failure scenarios:
- The secondary system is unavailable at the time of sending – Is the message saved in a queue and resent, or is it lost?
- The message arrives twice (a common problem with automatic Retry and Event Buses) – Does the receiving side create a duplicate record?
- Messages arrive out of order – Does a "canceled" status update arriving before "approved" result in incorrect outcomes?
A system not built as Idempotent (a unique identifier for each message + checking if it has already been processed) will fail precisely in the first two scenarios, and often under load – meaning exactly when the business is most reliant on it. API limitations and handling Throttling in this context are detailed in the Salesforce API Limits Resilience Guide.
Decision Framework: From Business Question to Pattern
| First Question Asked | If the Answer is "Yes" | If the Answer is "No" |
|---|---|---|
| Is a user on screen waiting for the integration result? | Synchronous Request-Reply with defined Timeout | Move to the next question |
| Is an update of a single change required within minutes? | CDC or Platform Event | Move to the next question |
| Do multiple different consumers need to know about the same event? | Event-Driven with Pub-Sub | Move to the next question |
| Is it convenient to process a large volume within a fixed time window? | Periodic Batch | Consider Fire-and-Forget with a queue |
This is a starting point for discussion in an architecture meeting, not an exhaustive formula – there are always edge cases (e.g., huge volume requiring CDC but also daily Batch Reconciliation as a safety net).
Illustrative Scenario: A Chain of Twenty Private Clinics
Consider a chain of clinics using Salesforce for patient inquiry management and a separate billing system that cannot be replaced at this stage. The requirement: when a patient completes an appointment, the billing system must be updated immediately, and when a payment is updated (e.g., payment received), Salesforce needs to reflect this so a service representative doesn't request double payment.
The team's initial choice was a bi-directional nightly Batch – simple to set up, but it created up to a 24-hour lag where representatives saw outdated information, leading to complaints. The solution ultimately chosen: one direction (appointment completion from Salesforce to billing) transitioned to Fire-and-Forget with a message queue and automatic Retry, because the user doesn't need to wait. The other direction (payment confirmation from billing to Salesforce) transitioned to CDC, as it was a specific change that needed to arrive within minutes. Nightly Batch remained only as a Reconciliation mechanism – a daily comparison that identifies and flags discrepancies, not as the primary update channel.
The result: update time decreased from hours to minutes, and the Reconciliation mechanism caught two instances of lost messages in the first month – exactly its purpose.
Risks and Specific Prevention Actions for Integrations
| Risk | How it Manifests in Practice | Prevention Action |
|---|---|---|
| Lack of Idempotency | Duplicate records after Retry or network failure | Unique message ID + existence check before creation |
| Undefined Source of Truth | Synchronization loop or random "winning" update | Defined Owner for each field + Conflict Resolution rule |
| Point-to-Point without Integration Layer | Any schema change in one system breaks another connection | Middleware/API layer with explicit versioned contracts |
| Technical Monitoring Only | Integration is "green" but orders are actually missing | Business Reconciliation metric, not just technical Uptime |
| Ignoring Governor Limits | Integration crashes precisely at peak load | Plan for Bulkification and Backoff proactively, not reactively |
Integration Pattern Selection Checklist
- ☐ Required response time defined in numbers, not just the word "fast"
- ☐ A single Owner defined for each shared field between systems
- ☐ What happens when the other side is unavailable has been checked and documented
- ☐ What happens when a message arrives twice has been checked
- ☐ What happens when messages arrive out of order has been checked
- ☐ A Reconciliation mechanism exists even when the primary pattern is asynchronous
- ☐ API limitations and Governor Limits have been checked against expected peak load volume
- ☐ Business rather than just technical success metrics have been defined
Metrics for Ongoing Integration Monitoring
After launch, it's advisable to track only three to four metrics: the success rate of messages on the first attempt, actual end-to-end time vs. defined SLA, daily Reconciliation discrepancies between systems, and proximity to API limits. A consistent rise in any of these – not just a one-off anomaly – is a signal to consider transitioning to a different pattern, before the system fails in production. Considerations for identity and access permissions between systems are detailed in the Salesforce SSO & Identity Architecture Guide.
Summary
Choosing the right integration pattern doesn't start with "which tool," but with three questions: how quickly is a response needed, who owns the data, and what happens when something fails. Real-Time is suitable when a user is waiting for a result; CDC and Event-Driven are suitable for rapid updates of a single change or distribution to multiple consumers; Batch is suitable for large volumes within a fixed time window. In every pattern, Idempotency, defined data ownership, and a Reconciliation mechanism are not "nice-to-haves" – they are prerequisites for the integration to withstand real load, not just a demo.
Professional Resources
- Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – CRM Architecture — https://hpi.pro/crm-architecture
- HPI Pro – Integrations & Data — https://hpi.pro/integrations-data