Real-Time vs Batch Integration in Salesforce: Key Differences and Use Cases
In Salesforce projects, choosing between real-time (event-driven) and batch integration is a fundamental architectural decision. Real-time integration means data flows immediately across systems (seconds or less), while batch integration moves data in scheduled chunks (minutes to hours). Each approach has its place: real-time is ideal for up-to-date transactions and user interactions, whereas batch is optimal for high-volume, non-urgent data loads. This guide explains the trade-offs of real-time vs batch integration in Salesforce, highlights common patterns (Platform Events, CDC, Bulk API, Batch Apex, etc.), and outlines when to use each method. We also touch on specific scenarios like Salesforce Service Cloud cases and large data migrations to illustrate practical usage.
Before choosing between real-time and batch processing, organizations should understand the broader Salesforce integration architecture and integration models.
Related guide:Salesforce Data Integration: Strategy, Mapping, and Synchronization Guide
What Are Real-Time and Batch Integrations in Salesforce?
Before evaluating the integration patterns available on the platform, it is important to understand how Salesforce integration architectures distinguish between real-time data processing and scheduled batch processing.
Real-Time Integration
It is called event-driven or streaming integration. means data changes in Salesforce or an external system are propagated instantly. In Salesforce, real-time patterns include Platform Events, Change Data Capture (CDC), Streaming API, Outbound Messages, and Apex callouts or flows triggered by record changes. For example, when an order is created, a Platform Event or CDC event can notify external systems immediately. Real-time sync ensures that data is fresh, which is critical for use cases like real-time alerts, live dashboards, or up-to-date customer interactions. However, real-time integration is more complex and may incur higher API usage (it “pushes” data as it happens), so it’s typically reserved for high-impact transactions.
Batch Integration
Batch integration involves moving data in bulk at scheduled intervals (e.g. nightly jobs or hourly batches). In Salesforce this often uses Bulk API, Batch Apex, or data loader tools. For example, a nightly ETL job might pull thousands of records from an ERP and insert them into Salesforce via Bulk API, or a Batch Apex job might update records in chunks. Batch excels when data freshness isn’t critical and volumes are large. As Zigiwave notes,
“Batch excels when freshness is not critical… Batch processing is not only sufficient, it’s preferred”
for large imports or reconciliation. In practice, “batch vs real time integration” boils down to latency vs throughput: batch jobs have higher latency (minutes to hours) but handle volume efficiently, whereas real-time methods have low latency (seconds) but scale differently.
Key Differences: Real-Time vs Batch Integration
Real-time vs batch integration requires looking at how data moves across systems and how Salesforce processes that information. Both approaches solve different architectural problems. Real-time patterns focus on immediate synchronization, while batch processes focus on volume efficiency and predictable processing windows. Testing both real-time and batch integrations should be a core component of any enterprise Salesforce sandbox strategy.
Latency and Data Availability
Latency is the most visible difference in batch vs real time integration patterns. In a real-time architecture, data moves between systems within seconds after a change occurs. Salesforce events, API calls, or message queues propagate updates immediately. This allows external platforms, analytics pipelines, or operational systems to react without waiting for scheduled jobs.
Batch integrations operate differently. Instead of processing records instantly, they collect records and process them at defined intervals. A batch job may run every hour, nightly, or at another scheduled time depending on business requirements. The tradeoff is that data becomes available later, but the processing workload is more predictable.
Use Case Alignment
Real-time integrations typically support operational processes that require current information. Customer support workflows, order processing, fraud detection, and notification systems depend on immediate updates. For example, Salesforce real-time integration is commonly used when a customer submits a request and a case must appear instantly in a support queue.
Batch processing is more appropriate for large operational datasets that do not require immediate synchronization. Historical data imports, nightly reporting updates, or financial reconciliation tasks often rely on Salesforce batch integration patterns. These processes handle large record sets without placing pressure on interactive transactions.
Throughput and Data Volume
Another important distinction in real-time vs batch integrations is how systems handle scale. Real-time integrations process events one transaction at a time. Each event represents a record change or message that triggers processing logic. This model provides responsiveness but limits the number of records processed simultaneously.
Batch processing focuses on throughput rather than immediacy. Bulk APIs and batch processing frameworks can process thousands or millions of records in a controlled execution window. Salesforce Bulk API and batch Apex jobs are designed specifically for high-volume processing scenarios where record-level immediacy is unnecessary.
Architectural Complexity
Real-time architectures are typically more complex to implement and maintain. Event-driven patterns require message delivery guarantees, error handling strategies, retry logic, and monitoring pipelines. Developers must design systems that can safely process asynchronous events and recover from partial failures.
Batch architectures are usually easier to maintain because they operate on scheduled execution patterns. A scheduled job runs, processes a defined dataset, and completes. Monitoring is simpler because failures occur within predictable batch windows.
Platform Limits and Resource Consumption
Salesforce platform limits also influence the decision between integration approaches. Real-time architectures generate more frequent API calls because each event or record change triggers a request. High-volume event streams must be carefully designed to avoid hitting API limits or event processing thresholds.
Batch processing reduces this pressure by grouping records together. Instead of thousands of individual transactions, bulk operations send large datasets in a single processing request. This approach aligns well with Salesforce asynchronous processing capabilities. Many organizations rely on external ID integration patterns to prevent duplicate records during large batch loads.
Failure Handling and Recovery
Failure recovery behaves differently in each integration pattern. Real-time systems isolate failures to individual transactions. If a single message fails to process, the integration can retry the event without affecting other transactions.
Batch jobs handle failures at a larger scope. When a batch execution fails, the system may need to reprocess a large set of records. However, Salesforce batch frameworks manage transactions in smaller chunks, which helps isolate partial failures and maintain data integrity.
Development Effort and Implementation Considerations
The final difference relates to implementation effort. Designing event-driven systems often requires additional infrastructure such as message brokers, event subscriptions, or streaming clients. Developers must also manage ordering, replay mechanisms, and idempotent processing.
Batch implementations tend to be more straightforward. A developer configures batch logic using scheduled jobs, integration middleware, or batch Apex real-time scenarios in Salesforce where asynchronous jobs perform controlled processing outside the user transaction.
For most enterprise architectures, the solution is not strictly one approach or the other. Instead, systems combine batch and real-time data integration depending on the operational requirement. Critical operational events are processed in real time, while large datasets move through scheduled batch pipelines. Following established Salesforce data integration best practices helps reduce integration failures and maintenance effort.
Latency and Throughput
Real-time integration delivers updates within seconds (ideal for up-to-the-minute data synchronization). Batch integration processes large volumes efficiently, but only on schedule. Batch systems are designed for processing large volumes of data efficiently, while real-time processing is optimized for immediacy, for example, Salesforce’s Bulk API can upload thousands of records in batches of 2000 at once, which is far faster than 2000 individual API calls, but this comes with minutes of delay instead of instant reflection of each record.
Use Cases and Risk
Use real-time Salesforce real time integration when data staleness introduces risk or delays (e.g. updating a customer case in Service Cloud, syncing instant transactions, or generating alerts). For instance, in Salesforce Service Cloud, immediate case updates and responses are crucial, so streaming changes into an operational dashboard benefits service teams. In contrast, batch integration is suited for predictable, high-volume tasks (data migrations, reconciliation reports, and cleanup jobs). The ZigiWave team highlights that batch is ideal for historical imports, compliance exports, and analytics loads. In summary, if stale data is acceptable or preferable (e.g., updates every hour/day), batch is stable and efficient; if data must move continuously, real-time wins.
API Limits and System Load
Salesforce enforces API limits. Real-time integration (Platform Events/CDC) reduces polling, but still consumes API calls per event processing. One resource suggests using Platform Events/Streaming API “rather than an external system polling Salesforce every 5 minutes for new orders” to reduce calls. Batch integration can mitigate limit issues by grouping records (Bulk API counts calls differently). For example, combining related upserts with the Composite API or using the Bulk API for mass updates lessens per-transaction overhead. However, extremely large batch jobs must be managed to avoid hitting concurrency or batch limits (Salesforce batch jobs are split into chunks of 200 records each transaction). A well-defined Salesforce API strategy helps organizations balance performance, scalability, and integration demand.
Development Complexity
Real-time patterns often rely on Salesforce’s event architecture (Platform Events, CDC). Developers must set up event definitions, write subscribers (Apex triggers on events or external clients), and handle schema changes. Batch integration typically uses familiar batch jobs or ETL tools, which many developers have experience with. For example, a Batch Apex class implementing Database.Batchable<SObject> processes records in chunks and can callout to external services asynchronously. This is straightforward, but it means the system processing might lag behind source updates. Understanding when to use middleware in Salesforce becomes increasingly important as integrations grow across multiple systems.
As integration environments become more complex, organizations often introduce middleware platforms to simplify connectivity, data transformation, monitoring, and error handling across multiple systems. Rather than building and maintaining dozens of direct point-to-point connections, middleware creates a centralized integration layer that improves scalability and governance. Popular Salesforce middleware integration tools can also help manage API traffic, orchestrate workflows between applications, and provide greater visibility into integration performance. This approach becomes particularly valuable when Salesforce must exchange data with ERP platforms, marketing automation systems, data warehouses, and other enterprise applications simultaneously.
Error Handling and Recovery
Real-time integrations usually isolate errors to single records or transactions, enabling immediate retries or compensation flows. Batch jobs may fail partially and require re-running large chunks or entire batches, which can create data gaps if not monitored. That said, batch jobs often have built-in retry or chunk-level rollback mechanisms (each chunk is a separate transaction).
In practice, many Salesforce projects combine both approaches: critical data flows use real-time events, while bulk data transfers happen in batch. As a rule of thumb, if the business requirement demands immediate consistency (e.g., live inventory tracking, service alerting, SLA enforcement), opt for an event-driven integration. If the workflow tolerates latency (e.g., nightly reports, legacy system migration, archival), a batch approach is safer and simpler.
Real-Time Integration Patterns and Tools in Salesforce
Salesforce offers several event-driven tools and APIs that support different Salesforce integration patterns. When a near-instant sync is required, Salesforce offers several event-driven tools and APIs:
Platform Events
A high-volume pub/sub mechanism on Salesforce’s event bus. Custom Platform Events can be defined and published via Apex, Process Builder, or Flow. Subscribers (other Apex triggers, external clients via the Streaming API or Pub/Sub API) receive the message immediately. For example, publishing a Order_Placed__e event after an opportunity closes allows any subscriber (like an order management system) to process it in real time. These real-time mechanisms implement an event-driven architecture in Salesforce.
Change Data Capture (CDC)
CDC is a built-in event mechanism that automatically publishes record change events (create/update/delete) for tracked objects (standard or custom). Instead of polling, downstream systems can listen to AccountChangeEvent, ContactChangeEvent, etc. This is ideal for replicating Salesforce data to analytics or data warehouses in real time. CDC effectively turns database changes into events.
Streaming API (PushTopics)
An older mechanism where SOQL queries define event notifications. Useful for specific queries (e.g. notify when certain criteria are met). Less commonly used now than Platform Events/CDC for new implementations, but still available.
Outbound Messaging
Configured in Workflow/Process Builder; Salesforce sends SOAP messages to a listener when records change. It’s reliable (automatic retries) but limited in throughput and flexibility, so it’s often used only for simple real-time needs.
Apex Callouts
Synchronous callouts from triggers or asynchronous (Future, Queueable) to push data out. Use this when immediate outbound action is required, and you control the external endpoint. Beware callout limits and transaction coupling.
Named Credentials & External Services
For integrating REST/SOAP services without hard-coding credentials. These support real-time callouts with better security, often used with Apex or Flow.
These real-time mechanisms implement an event-driven architecture in Salesforce. They enable patterns like Publish-Subscribe or Change Data Capture. For instance, an order fulfillment system might subscribe to Salesforce events via the Streaming API to get immediate updates on order changes. The event-driven model ensures that as soon as Salesforce data changes, those changes are pushed to other systems, enabling near-zero latency synchronization.
Example (Apex Trigger on CDC event):
// Apex trigger on Change Data Capture event
trigger AccountChangeTrigger on AccountChangeEvent (after insert) {
for (AccountChangeEvent evt : Trigger.new) {
// Process the change, e.g., call out to an external system
System.debug(‘Account changed: ‘ + evt.ChangeType + ‘ – ‘ + evt.Name);
}
}
This trigger fires the moment an Account record is created/updated/deleted, and an external integration (or internal process) can react in real time.
Batch Integration Patterns and Tools in Salesforce
Batch integration handles large data volumes or non-urgent updates. Common approaches include:
Salesforce Bulk API (v1 & v2)
REST-based APIs for loading or deleting up to millions of records asynchronously. Data is sent in “batches” of records (up to 10,000 per batch for Bulk API 2.0), for example, uploading 10,000 account records overnight. Bulk API is ideal for large initial loads or mass data updates. As noted, Bulk API can process thousands of records per call, making it much faster than repeated single-record calls.
Batch Apex
Apex classes implementing Database.Batchable<SObject> can process up to 50 million records in chunks of up to 200. A Batch Apex job can include callouts, perform transformations, and continue in batches. For example, a Batch Apex job could query thousands of invoices and send them to an accounting system. Using finish() methods, you can chain jobs or send completion notifications. Batch Apex is useful for scheduled or one-off jobs within Salesforce.
Scheduled Apex
Regular Apex jobs (using the Schedulable interface) can invoke logic (like callouts or batch jobs) at fixed intervals (e.g., nightly). This is useful for periodic syncs or housekeeping tasks that can wait.
Data Loader / ETL Tools
External applications (Salesforce Data Loader, Talend, Informatica, etc.) often use Bulk API or SOAP APIs to import/export data in bulk. For example, a data migration service might run a Data Loader process every morning to pull new customer data from an ERP.
Composite API
For scenarios where many related records must be created but the total count is moderate, the Composite REST APIs can bundle multiple sub-requests into one call, reducing round-trips. This can be used in synchronous or asynchronous modes.
Batch processes are especially effective for data migrations and heavy integration loads. For instance, a Salesforce data migration service project often involves moving historical data into Salesforce this is naturally done via batch jobs. Similarly, if integrating with legacy systems that only support nightly updates, batch is the only option. The trade-off is that changes won’t appear instantly in Salesforce; teams must wait for the next run. But this is acceptable for things like monthly reports or quarterly audits.
Example (Batch Apex template):
global class UpdateContactsBatch implements Database.Batchable<SObject> {
global Database.QueryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator(‘SELECT Id, Email FROM Contact WHERE LastModifiedDate = LAST_N_DAYS:1’);
}
global void execute(Database.BatchableContext bc, List<Contact> scope) {
// Example: update all contacts in the batch (or send them to an external API)
for (Contact c : scope) {
c.Email = c.Email.toLowerCase();
}
update scope;
}
global void finish(Database.BatchableContext bc) {
// e.g., send notification or call another batch
}
}
This Batch Apex class processes recent contacts in chunks. It could be scheduled to run nightly, representing a batch integration approach. ERP integrations often follow this pattern as well. In an Acumatica Salesforce integration, financial transactions, invoices, or inventory updates may be synchronized in scheduled batches while critical customer or order events are processed through real-time APIs.
When to Use Real-Time vs Batch (Trade-Off Considerations)
To choose the right approach, consider the following factors:
Data Freshness vs Volume
If business processes require immediate updates (e.g., an urgent service case, financial transaction, customer login triggers data sync), use real-time. If you need to process millions of records where a delay is acceptable (e.g., syncing product catalogs, bulk financial data), use batch. Essentially, if “how fast” is critical, pick real-time; if “how much” is more critical and delays are fine, pick batch.
System Load and Limits
Real-time integration tends to produce a higher frequency of API calls and can spike system load unpredictably. Batch integration groups calls and can run during off-peak hours to minimize impact. For example, to avoid hitting Salesforce API limits, it’s common to run heavy data syncs at night. The ZigiWave blog notes that batch processing gives “predictable load” and “controlled throughput,” which can reduce costs and system strain.
Error Recovery and Visibility
Real-time events usually report failures immediately (you can retry a failed event or alert user right away). Batch jobs may require logs to detect failures and sometimes re-run large data sets. Choose real-time for high-priority processes where immediate error handling is needed. For less critical updates, batch with logging is sufficient.
Integration Complexity and Skillset
Real-time integrations often require an understanding of event-driven architecture and subscription mechanisms (COMETD, MQTT, etc.). Batch integrations can often be done with ETL tools or scheduled code that many developers are already familiar with. Organizations should factor in their team’s expertise.
Business Scenarios
Some scenarios clearly align with one method:
- Service and Support (Service Cloud): Real-time sync of cases and status updates keeps agents informed. E.g., a new support case in an external portal should appear instantly in Salesforce Service Cloud for agents to act on.
- Mobile or Store Apps: Point-of-sale or field apps often need real-time inventory or pricing from Salesforce.
- Analytics and Data Warehousing: Often powered by batch ETL (though streaming architectures are emerging, many use nightly CDC loads).
- Legacy Migrations: Importing large archives or converting old databases usually uses batch processes, as immediate consistency with legacy isn’t required beyond the batch window.
- Bi-directional Sync: Sometimes a hybrid approach is used, where recent changes are pushed via events, while a nightly job syncs any missed changes or historical data.
For example, a Salesforce Data Cloud Consulting engagement might involve architecting a solution where real-time event streams feed a customer 360 data platform, while nightly batch jobs backfill any data gaps. The consulting team would design both pipelines.
Practical Example: Real-Time vs Batch in Action
Consider a company syncing Salesforce with an external order management system:
Real-Time Path
Every time a Salesforce Order object is created or updated, a Platform Event is published. An external listener (via the Streaming API) picks up the event and updates the external system immediately. Users see the order status in near real time across systems. If a down-the-line alert (e.g. payment failure) occurs, an outbound Platform Event notifies Salesforce instantly to create a case in Service Cloud. This live integration improves responsiveness and customer experience.
Batch Path
Alternatively, the company could run a nightly integration job: at 2 AM, a scheduled process retrieves all orders from Salesforce and sends them to the order system in bulk (using Bulk API or a data integration platform). The external system processes them before morning. While efficient in throughput (handling thousands of orders at once), any order created at 3 AM won’t reach the other system until the next day, introducing a lag. If that lag is acceptable (e.g. for invoicing purposes), this simple batch strategy may suffice. However, the Order-to-Cash Process in ERP often involves multiple stages, including order creation, fulfillment, invoicing, and payment, so architects should determine which transactions require real-time synchronization with Salesforce and which can move through scheduled batches.
Complex ERP environments often require specialized expertise. Many organizations work with experienced Salesforce ERP integration companies to design integration architectures that balance real-time processing, batch synchronization, and long-term scalability.
A common example appears in project management environments where a monday.com Salesforce integration synchronizes opportunity updates, tasks, or account activity. In these scenarios, teams often choose real-time synchronization for status updates while running batch jobs for reporting data or historical task synchronization.
In reality, many enterprises use both: critical orders (e.g. high-value or time-sensitive ones) might go through real-time APIs, while the rest are handled in batch. The key is matching the integration style to the business need.
Integrating with Salesforce Clouds and Services
When designing integration patterns, consider specific Salesforce clouds and services:
Salesforce Service Cloud
Service Cloud is case-centric and often requires up-to-date customer data. Real-time integration ensures support reps see the latest information. For example, changes in a logistics system can push updates to Case records via CDC so agents work with the most current status. In many implementations, Salesforce Service Cloud consulting efforts focus on defining which service events require immediate synchronization and which datasets can move through scheduled integration jobs. Batch integration can still play a role; for example, nightly updates of service entitlements or knowledge articles can be processed in controlled batches without affecting agent workflows.
Data Migration
Large-scale data migrations, such as moving thousands of contacts or historical cases during a CRM consolidation, are inherently batch-driven processes. Tools like Data Loader or Bulk API are typically used to process large datasets in controlled execution windows. A common example is a Salesforce classic to Lightning migration, where historical records, attachments, and configuration data may need to be validated and migrated in stages. In these scenarios, batch processing allows teams to load data with minimal disruption while validating records in structured chunks before the system becomes fully operational.
Salesforce Implementation Services
During an implementation project, architects decide upfront which integration style each connection will use. For instance, they might choose real-time web services for CRM-ERP price checks (to give sales reps instant availability info), but use nightly batch jobs for product catalog updates. Implementation services should consider licensing (e.g., having CDC/Event licenses for real-time) and platform design (avoiding hitting limits).
In short, Salesforce batch integration scenarios cover things like migration, periodic syncs, and reports; Salesforce real-time integration scenarios cover live sync of transactions, customer interactions, and event-driven automations. Modern implementations often real time integration logic (Platform Events, Pub/Sub API) combined with batch processes for completeness.
Summary
When architecting Salesforce integrations, the real-time vs batch integration choice hinges on immediacy versus volume. Real-time (event-driven) integration offers immediate consistency using Platform Events, CDC, and streaming APIs; it’s best for time-sensitive, high-priority data flows. Batch integration (Bulk API, Batch Apex, scheduled jobs) offers efficient handling of large volumes with minimal latency requirements. Many Salesforce solutions leverage both: critical updates are pushed instantly, while bulk data moves in scheduled batches.
Factors like data freshness requirements, API limits, and system load. For example, use Platform Events or CDC (real-time) to push case escalations into Service Cloud, but use Bulk API or Batch Apex (batch) for nightly contact or product catalog syncs. Effective integration design might be summarized as: “Event-driven for immediacy, batch for mass data.” By aligning each scenario with the right approach, a Salesforce integration remains robust, scalable, and cost-effective.
Real-Time vs Batch Integration in Salesforce isn’t an either/or choice but a toolset. Architectures that skillfully combine event-driven streams with periodic batch jobs achieve both timely data and high throughput.
Leave Comment
Was this blog helpful?
Was this blog helpful?