Real-Time vs. Batch Salesforce Integration: The Question That Actually Decides It

Change Data Capture will drop events when a nightly SAP load or a mass data update pushes an org past its daily delivery allocation - and Salesforce doesn't send an alert when it happens. That's documented platform behaviour, not an edge case, and it's exactly the kind of thing that turns "we made this integration real-time" from a modernisation win into a downstream system that's quietly wrong for three days before anyone notices.

Most comparisons of real-time vs. batch Salesforce integration frame it as a maturity question: real-time is the modern choice, batch is what you run until you can afford better. That framing is backwards often enough to be worth correcting. The question that actually decides it is narrower and less flattering: when this integration fails - and every integration eventually does - will someone notice, and how long will it take? A Salesforce Health & Roadmap review's integration section exists specifically because that question rarely gets asked before go-live.

The short answer

Batch is the safer default for most Salesforce-to-ERP integrations, because a failed batch job is loud - it errors, it shows up in a log, and rerunning it fixes yesterday's problem today. Real-time integration (Platform Events, Change Data Capture, or the Pub/Sub API) earns its added complexity only where a few hours' staleness genuinely costs money or trust, and only if the team is willing to build monitoring for a failure mode batch jobs don't have: events that vanish with no error at all. Most organisations that run both patterns well didn't pick one over the other - they run a short, deliberate list of real-time triggers alongside a batch job that reconciles everything else. The framework below is for deciding which fields belong on which list.

Why "make it real-time" is the wrong first question

The push toward real-time integration usually comes from a stakeholder's discomfort with delay, not a measured cost of it - "the sales team shouldn't have to wait until tonight" is a feeling, not a figure. The actual cost of real-time is operational, and it's paid by whoever ends up supporting the integration, not by whoever requested it: idempotent processing so a retried event doesn't double-write, dead-letter handling for the events that fail on arrival, and someone who watches delivery-allocation usage the way a DBA watches disk space. Skip that work and real-time integration is still fast - it's just fast and unmonitored, which is a worse combination than slow and reliable.

The allocation problem is the part most teams don't find out about until it bites them. Change Data Capture and Platform Events run on the same event bus and the same daily delivery allocation, and that allocation is consumed per subscriber, not per published event - publish 1,000 changes to ten subscribing systems and that's 10,000 deliveries against the daily ceiling, not 1,000. Depending on edition, Salesforce's published allocations put that daily ceiling anywhere from roughly 10,000 deliveries (Developer edition) up to 50,000 (Performance and Unlimited editions) on a rolling 24-hour window - worth confirming against your own edition rather than assuming, since editions and add-ons change what you're actually working with. A single nightly ETL job, batch Apex update, or mass data load can burn through that allocation in minutes. When it does, the excess events don't queue, retry later, or bounce back with an error - they're dropped, and nothing in standard Salesforce monitoring tells you it happened.

The decision framework

Why real-time fails differently than batch does

A batch job that fails is almost considerate about it: it errors, the error lands in a log or an inbox, and the fix is usually "rerun it." Nobody has to go looking for the problem, because the problem announces itself. A real-time integration built on Change Data Capture or Platform Events can fail in a way that looks, from the outside, exactly like success - every event that was delivered was processed correctly, and the ones that weren't delivered simply never existed as far as the subscriber is concerned. That's the shape of the allocation-overflow failure specifically, and it's worth walking through once so it's recognisable in your own org rather than discovered by a customer first.

The hybrid pattern most orgs actually run

Treat this as a design decision made once, deliberately, rather than a default either pattern backs into over time.

1. Name the short list of fields where minutes genuinely matter - a credit hold, a fraud flag, a stock level hitting zero - and put only those on Platform Events or Change Data Capture.
2. Leave everything else on a scheduled batch job, on whatever cadence the business actually needs, not whatever cadence feels current.
3. Build one alert that matters: delivery-allocation usage approaching the daily ceiling, not a generic "job completed" email nobody reads by the third week.
4. Run a reconciliation job regardless of pattern - daily is usually enough - so a silently dropped event or a batch job that quietly stopped running both get caught within a day, not a quarter.

Questions worth answering before you build either pattern

Is Change Data Capture the same thing as Platform Events?

No. Change Data Capture publishes standard change events automatically for objects you enable it on; Platform Events are custom event objects you define and publish deliberately from Flow or Apex. Architecturally, though, they share the same event bus, the same subscriber model, and the same daily delivery allocation - so the overflow risk described above applies to both, not just to Change Data Capture.

Doesn't MuleSoft or other middleware solve this for us?

Middleware changes where the integration logic and error handling live - it doesn't change whether the underlying Salesforce event bus allocation exists. A middleware layer subscribing to CDC or Platform Events still consumes deliveries against the same daily ceiling, and still needs its own alerting to notice a gap rather than assuming Salesforce will flag one. It's a genuinely good place to put retry and dead-letter logic; it's not a reason to skip monitoring the allocation itself, and it doesn't remove the need to have decided which system owns which field before the sync goes live.

How do we check if we're already close to the allocation?

Event Monitoring and System Overview in Setup show delivery volume, but neither one proactively warns you as usage climbs toward the daily ceiling - that alert has to be built. If Platform Events or Change Data Capture are already running in your org and nobody could tell you today how close to the allocation last night's load came, that's worth treating as an open question rather than an assumption everything's fine. It's exactly the kind of gap a Salesforce Health & Roadmap review's integration section is built to surface.

The bottom line

Real-time isn't the mature choice by default, and batch isn't the legacy one - they're two different failure modes, and the one worth picking is whichever your team can actually operate when it breaks at 2am, not whichever sounds more current in a planning meeting. If that's a genuinely open question in your org right now, it's worth answering deliberately rather than letting whichever pattern got built first become the permanent answer by accident. Our architects see this trade-off most often in Salesforce-SAP and Salesforce-ERP integrations specifically, and Salesforce Expertise as a Service exists for exactly this kind of ongoing operational discipline rather than a one-off build - talk to us if you'd rather get a second opinion before the next integration ships.