Mastering Synchronous vs Asynchronous Integration Patterns in Salesforce

Consider how you communicate in your day-to-day life. When you want a quick response, like to find out whether a colleague is available for a meeting immediately, you phone them. You hold the line for their answer before you make the next move. But for the types of interactions where you have information to convey but don’t need an immediate response, a detailed project update, for example, you fire off an email and get on with your day, confident that they’ll reply when they can.

This basic difference of phone calls versus emails is echoed in one of the most important design decisions in salesforce integrations: deciding between synchronous and asynchronous communication styles. In the same way you wouldn’t call someone at 3 AM about a question that’s not urgent, don’t make your systems wait in real time for processes that can run behind the scenes.

In this guide, we’ll explore the complete landscape of Salesforce integration patterns, with a deep dive into synchronous vs asynchronous approaches, complete with real-world use cases from financial services and manufacturing industries.

The Salesforce Integration Pattern Landscape

Before Jumping into sync vs async, let’s first cover the main integration patterns within the Salesforce world,

• Request-Reply (Synchronous): An interactive, synchronous session in which the caller is waiting for the response. Think REST/SOAP APIs with timeout constraints.
• Fire-and-Forget (Asynchronous): It is true one-way communication in which the sender does not wait for acknowledgement. Platform Events and outbound messages follow this pattern.
• Batch Data Synchronization: Scheduled bulk operations for large datasets. Salesforce Bulk API and scheduled ETL jobs operate this way.
• Remote Process Invocation: Salesforce triggers an external process without waiting. May be useful for long-running tasks such as report generation or intensive computations.
• UI Update via Streaming: Updates get pushed from the server to client UIs through Streaming API or CometD enabling real-time dashboards with no need for polling.

Synchronous Integration: The Phone Call Model

How It Works

Imagine you have just received a call from your bank’s fraud department. You’re about to hang up after reporting a suspicious charge, and you’re holding while they run a check through their systems. You can’t hang up, you need their answer before you know whether to cancel your card. It is an example of synchronous communication: a blocking request-response where the caller is waiting for a response.

In Salesforce, synchronous integrations work identically. After clicking “Validate Address” in a form, the user Salesforce sends a real-time API call to an address validation/proofing service, wait for the response, and then shows the validated address or error message. The system blocks on the user’s action until the external system responds.

Technical Characteristics

• Blocking execution : The calling thread waits for the response. Salesforce governor limits impose a 120-second timeout for callouts.
• Immediate response required: The external system must respond quickly, typically within 5-10 seconds for good UX.
• Transactional consistency: The entire operation succeeds or fails as a unit. If the external call fails, you can rollback the Salesforce transaction.
• Resource intensive: Holds database connections, API limits, and processing threads during the wait.

When to Use Synchronous Integration

Choose synchronous patterns when the user or process cannot proceed without the result:

• Validation workflows: Credit checks, address verification, inventory availability checks
• User-initiated actions requiring immediate feedback: Payment processing, account creation, real-time pricing
• Transactional data that must be consistent: Creating a customer record that must exist in both Salesforce and the billing system before proceeding
• Rule of thumb: If the response changes what happens next in the workflow, use synchronous integration.

Asynchronous Integration: The Email Model

How It Works

Imagine writing an email to your IT help desk at work about some software problem. You explain the issue, hit send, and get right back to work. You don’t wait around staring at your inbox for a response, you know they’ll get to it when they can, and you’ll be notified when there’s an update. This is asynchronous communication: fire­hazard and forget, non-blocking communication.

In Salesforce, asynchronous integrations operate the same way. When a sales rep closes an opportunity, Salesforce might publish a Platform Event that triggers warehouse systems to prepare shipment, accounting systems to generate invoices, and analytics systems to update dashboards. The sales rep isn’t waiting on any of these, they’re already off to the next deal. The downstream systems consume these events according to their own schedules.

Technical Characteristics

• Non-blocking execution: The sending system continues immediately without waiting. Processing happens in background workers or separate systems.
• Eventual consistency: Data synchronizes across systems over time, not instantly. You accept a window where systems may be temporarily out of sync.
• Higher throughput: There is no waiting because you can handle massive amounts of it. Perfect for mass transactions or high frequency transactions.
• Decoupled systems: Publishers don’t need to be aware of subscribers. Systems can fail individually without cascading failure.
• Complexity in error handling: Need dead-letter queues, retry mechanisms, and monitoring since failures aren’t immediately visible.

When to Use Asynchronous Integration

Choose asynchronous patterns when the result doesn’t affect the current workflow:

• Background processing: Report generation, data enrichment, analytics updates
• Long-running operations: Batch jobs, document generation, complex calculations that exceed timeout limits
• Event broadcasting: Notifying multiple systems about state changes without coupling them
• High-volume data flows: IoT sensor data, transaction logs, audit trails
• Rule of thumb: If the user can continue working without the result, use asynchronous integration.

Synchronous vs Asynchronous Integration Patterns: The Critical Differences

To extend our communication analogy further, consider three scenarios:

• Emergency call to 911 (Synchronous): You need immediate help, you wait on the line, and the dispatcher coordinates response in real-time. The call doesn’t end until you have confirmation help is coming.
• Leaving a voicemail (Asynchronous): You leave your message and move on with your day. The recipient will respond when available. You’re not blocked waiting.
• Radio broadcast (Fire-and-Forget Async): The station broadcasts to potentially thousands of listeners. The broadcaster doesn’t know who’s listening or wait for acknowledgment. Messages reach whoever is tuned in.
• High-volume data flows: IoT sensor data, transaction logs, audit trails

Key Architectural Tradeoffs:

• Latency vs Throughput: Synchronous optimizes for low latency (fast individual responses) but limits throughput. Asynchronous accepts higher latency per operation but achieves massive throughput.
• Consistency vs Availability: Synchronous ensures strong consistency, everyone sees the same data immediately. Asynchronous provides high availability, systems stay responsive even if some components fail, but data consistency is eventual.
• Coupling vs Complexity: Synchronous provides tight coupling between systems but error handling is simpler (failures are immediate). Asynchronous allows for loose coupling but it needs complex error handling, monitoring and recovery.
• Resource Utilization: Synchronous ties up resources (threads, connections) while waiting. Asynchronous frees resources immediately but requires message queues and worker processes.

The choice isn’t about which is ‘better’, it’s about matching the pattern to the business requirement.

Real-World Use Cases: Financial Services
Synchronous: Credit Card Authorization

Scenario: A customer applies for a credit card through a Salesforce Community portal. Before finalizing the application, the system must verify credit score, check for fraud flags, and determine credit limit.

Why Synchronous? The customer is waiting on the screen. They can’t proceed to the next step (accepting terms, confirming details) until they know if they’re approved and for what amount. The business needs to present the offer immediately.

Implementation: Salesforce makes a synchronous REST callout to the bank’s credit decisioning engine. The API returns approval status, credit limit, and APR within 3-5 seconds. If approved, the application advances to the acceptance stage. If denied, the customer sees alternative offers.

Risk mitigation: Add circuit breakers and fallback logic. When the credit system is unavailable, hold applications for manual review, rather than displaying errors to customers.

Asynchronous: Regulatory Reporting

Scenario: When a wealth management advisor creates or modifies an investment portfolio in Salesforce, the system must notify the compliance department, update risk analytics dashboards, and submit filings to regulatory systems.

Why Asynchronous? The advisor needs to save the portfolio and go to the next client, they do not have to wait for compliance processing. Downstream processing such as these can take minutes to hours, way beyond synchronous timeout thresholds. And the advisor’s work shouldn’t be blocked if the compliance system is down for the moment.

Implementation: Use Salesforce Platform Events. When the portfolio is saved, publish a PortfolioModified__e event containing the portfolio ID, advisor details, and change summary. Downstream systems subscribe to this event stream and process independently: compliance runs risk checks, analytics recalculate exposure metrics, and regulatory systems prepare filings.

Reliability pattern: Implement replay storage for Platform Events (24-hour retention). If a subscriber system is down during an event, it can replay missed events when it comes back online.

Real-World Use Cases: Manufacturing
Synchronous: Inventory Availability Check

Scenario: A sales representative is building a complex manufacturing order in Salesforce CPQ. They have to find out if individual parts are in stock at several warehouse locations before they can give the customer a delivery date.

Why Synchronous? The rep is on the phone with the customer right now. They can’t finalize pricing or delivery commitments without knowing what’s in stock. If a critical component isn’t available, they need to suggest alternatives immediately.

Implementation: As the rep picks products in CPQ, Salesforce is making synchronous API calls to the inventory module of the enterprise resource planning (ERP) system. The API provides current stock levels, warehouse locations, and lead times for unavailable products. This information is directly populated in the quote UI for instant decision making.

Performance optimization: Cache API responses for 5 minutes for items that are checked frequently. Batch multiple SKUs in single API call to reduce latency.

Asynchronous: IoT Sensor Data Processing

Scenario: Manufacturing equipment on the factory floor has IoT sensors monitoring temperature, vibration, and pressure. These sensors generate readings every second. When sensors detect anomalies, they should create service cases in Salesforce, but normal operational data should feed into analytics for predictive maintenance.

Why Asynchronous? Sensors generate thousands of data points per minute, far too many for synchronous processing. The factory floor operations don’t depend on Salesforce receiving this data immediately; they need reliable eventual delivery. Also, Salesforce shouldn’t become a bottleneck if it experiences temporary performance issues.

Implementation: Sensors publish data to an apache kafka topic. A middleware component is a consumer from kafka topic , it aggregate the data (averages per minute e.g) and then publish to salesforce platform events. Salesforce handle those events asynchronously: normal reads are pushed to analytics cloud, anomaly events trigger automated case creation through Process Builder / Flow.

Scalability strategy: Use event batching, combine up to 100 sensor readings into a single Platform Event. This dramatically reduces API consumption and improves throughput from ~2,000 to ~200,000 readings per hour.

Conclusion
Understanding the difference between synchronous and asynchronous integration patterns is key to designing scalable, reliable solutions on the Salesforce platform. After all, you shouldn’t be calling someone at midnight for a non urgent question, or be on hold for hours for information that could be coming you by email, and your systems should adopt the communication pattern that best fit the business need.

Synchronous integrations, like phone calls are perfect when you need immediate feedback to proceed: credit checks, inventory lookups, real-time validation. This results in better consistency, simpler error handling, but at the cost of coupling of systems and limited throughput.

Asynchronous integrations, such as emails and broadcasts, work best when you can perform operations in the background: reporting, notifications, processing batches, executing event-driven workflows. They facilitate huge scale and system resilience but necessitate complex error handling and eventual consistency.

The best enterprise architectures don’t choose one pattern exclusively; they combine both strategically. A single business process might use synchronous integration for user-facing validation steps and asynchronous patterns for downstream processing, notifications, and analytics.

As you design your next Salesforce integration, remember: the goal isn’t to be purely synchronous or purely asynchronous, it’s to match the communication pattern to the business requirement, ensuring your systems are as responsive, reliable, and efficient as the way you communicate in everyday life.

The post Mastering Synchronous vs Asynchronous Integration Patterns in Salesforce first appeared on AYAN Insights.