Mastering Salesforce Integration Patterns: A Technical Guide to Sync vs Async Integration

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.

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

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.

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.

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

Rule of thumb: If the user can continue working without the result, use asynchronous integration.

To extend our communication analogy further, consider three scenarios:

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

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.

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.

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.

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.

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.