Skip to main content

Batch vs. real-time activation: scheduled segment publish or a real-time data action

The decision the whole subcategory turns on: a scheduled segment publish recomputes a whole audience on a cadence and ships it to an activation target; a real-time data action fires off a single data change as it happens. One answers 'who, as of the last run'; the other answers 'react now to this one change'. The two mechanisms, their real limits, and how to tell which one a requirement actually needs — the exact parallel to the query layer's Calculated-Insight-vs-live-Query call.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

This is the page the Segmentation & Activation subcategory turns on. Every other page here — building the segment, choosing the target, the Marketing Cloud bridge, consent — assumes you already know how the audience leaves Data 360 (formerly Data Cloud). There are two mechanisms, they are not interchangeable, and reaching for the wrong one is a rebuild, not a setting you flip. So before any of those decisions, this one: a scheduled segment publish or a real-time data action.

The shape of the call is identical to the central decision in the query layer (Calculated Insight vs. live Query). There, the fork is compute once and let everyone retrieve versus run it live every time. Here it is recompute a whole population on a cadence versus react to one change as it happens. Same instinct underneath, same failure when you guess: you either freeze an event need into a daily batch, or you wire an event mechanism where the job was actually a population.

The two mechanisms, side by side

A segment publish and a data action answer different questions. State them in one line each and most confusion dissolves:

Scheduled segment publish → "who is in this audience, as of the last run"  (a population, on a cadence)
Real-time data action      → "react now to this one change"                 (an event, as it happens)

A scheduled segment publish recomputes the segment's entire membership on a cadence and pushes the result to an activation target — Marketing Cloud, an ad platform, a file in a bucket. It is the full audience: every filter, every container, every Calculated Insight the segment references, evaluated against the model and resolved into a list of people. Its latency is the publish interval — the audience is exactly as fresh as the last run (building segments covers the freshness mechanics).

A real-time data action is a different thing entirely. It does not recompute an audience. It watches for a single data change — a record created, updated, deleted — and fires off a message about that one change the moment it propagates. It is event-shaped: it reacts to one thing, it does not produce a population. Salesforce builds it on the platform's change data feed (the change data capture mechanism), which is why its timing is near-real-time, not instantaneous — more on that below.

The trap is that both can end up pointed at Marketing Cloud, so they look like two settings for the same job. They are not. One ships an audience on a clock; the other relays an event as it occurs.

Scheduled segment publish: the two cadence tiers

A segment publish is not one speed. There are two tiers, and the faster one buys speed by giving up reach.

Standard publish — the deep, complete audience

Standard publish runs on a schedule in the 12-to-24-hour range and evaluates against a long engagement horizon: up to two years of engagement history, with a default lookback of 90 days that you configure up from there. It works with any activation target — Marketing Cloud, advertising platforms, cloud storage, the lot. This is the default and the one most audiences want: full segment expressiveness, the complete history, every destination available. The cost is latency measured in hours — the audience is a snapshot from the last run, up to a day old.

Rapid Segment Publish — fresher, but narrower on every axis

Rapid Segment Publish refreshes far more often — on a 1-hour or 4-hour cadence — but it trades reach for that speed on three axes at once:

  • Horizon. It evaluates only the last 7 days of engagement, not the two-year history standard publish can reach. A rule that depends on behavior older than a week can't be expressed in a rapid segment.
  • Destination. It is built for Marketing Cloud Engagement as its target. (Salesforce has extended rapid publishing to some additional target types over time — confirm what your org's version supports before you design around it; treat Marketing Cloud as the dependable case.)
  • Volume. There is a cap on how many rapid segments an org can run, and an existing standard-schedule segment generally can't be flipped to rapid after the fact — you choose the cadence as a property of the segment, not as a dial you turn later. Both are org- and version-specific limits; verify the current numbers in your org rather than committing to a figure from a doc.

Either tier, the thing being shipped is the same: a recomputed population. The cadence sets the latency. What it can't do is react to a single change between runs — that is the other mechanism.

Real-time data action: an event, not an audience

A data action publishes a single data change to a target as it happens. You configure it against an object and a condition — when a record like this changes — and when the change propagates through the platform, the data action fires a message describing it. Three target types receive it:

  • A Salesforce platform event — dropped onto the platform event bus, where it is very often consumed by a platform-event-triggered Flow that does the downstream work. This is the common shape when the reaction lives inside Salesforce.
  • A webhook — an HTTP request to an external endpoint, carrying the change as a payload, for a system outside Salesforce to act on.
  • Marketing Cloud — the change is sent to Marketing Cloud Engagement, where it can drive an entry event or a streaming interaction.

The defining property: a data action reacts to one change, it does not evaluate a whole audience. There is no membership, no population count, no "everyone who currently qualifies." There is a change, and a message about it. That is exactly why it is fast — there is nothing to recompute — and exactly why it can't answer "who is in this segment." Different question, different tool.

"Real-time" is near-real-time, with limits

A data action is fast, but it is not instantaneous and it is not unbounded. Salesforce's own framing is near-real-time: the change propagates through the change data feed and out to the target with real latency, governed by documented limits and guidelines — not by zero. Promising a client "instant" and architecting as if a data action were a synchronous callback is how a launch slips when the real behavior turns out to be near-real-time with caps on throughput.

The decision: which question are you actually answering

The whole call reduces to one separation. Two questions hide inside most requirements and look like one:

  1. Who is in this audience? — a population, evaluated against the model. That is a segment, and a segment ships via a scheduled publish.
  2. When must the destination act? — on a cadence, or the moment one thing changes. A cadence is the publish interval; "the moment it changes" is a data action.

Answer both, out loud, before you build:

Need a population, refreshed on a clock?            → scheduled segment publish (standard, or rapid if it fits the 7-day window + MC)
Need to react to a single change as it happens?     → real-time data action (platform event, webhook, or Marketing Cloud)
Need a population AND an immediate per-change react? → BOTH — two mechanisms, not one stretched to cover both

That last line is the one teams miss. "Email everyone in the high-value segment, and also fire a message the instant any one of them abandons a cart" is not one mechanism on a clever setting. It is a segment publish for the population and a data action for the per-change reaction — two builds, wired separately, each doing the job it is shaped for. Naming which one (or both) a requirement needs is the cheapest step in the whole subcategory, and skipping it is the most expensive.

The symmetrical mistakes are predictable. Reaching for a daily-published segment to satisfy a "the moment they do X" requirement gives you a reaction that is up to a day late. Wiring a data action where you needed a recomputed audience gives you a stream of per-change events and no population to send a campaign to. Both compile. Both look plausible in a demo. Both are a rebuild once the requirement is real.

The parallel to the query layer, stated plainly

This is deliberately the same fork as Calculated Insight vs. live Query, one layer over. There, you compute a metric once and let every consumer retrieve it, or you run it live each time it's asked — and freshness is "as fresh as the freshest decision it feeds," never "as fresh as possible." Here, you recompute a whole audience on a cadence, or you react to one change as it happens — and the same freshness discipline applies: set the publish cadence to the freshest decision the audience feeds, and don't reach for a data action's immediacy where a daily population was the actual job.

The honest test, in one line: if the requirement is "who currently qualifies," it's a segment publish; if it's "react to this one change now," it's a data action — and if it's genuinely both, build both. Most "should this be batch or real-time" debates dissolve the moment you say out loud whether the destination needs a population or a per-change reaction.

Related

Reference: