Data 360 automation: Data Cloud-triggered flows vs. Data Actions vs. activations

You’ve unified your data in Data 360, computed an insight nobody could compute before — a propensity score, a lifetime-value bracket, a cart that just went quiet — and now you want that signal to do something. Create a follow-up task. Post to an external system. Kick off a marketing journey. Fair ask. So you open the platform and find not one way to react to a Data 360 change but four: a Data Cloud-triggered flow, a Data Action, an activation, and — new in 2026 — an activation-triggered flow. They sound interchangeable. They are not. One fires inside Salesforce a few minutes after the fact; one pushes to an external endpoint in near-real-time but never actually “calls” your automation directly; one is a scheduled batch; one is an orchestration layer on top of that batch. Pick the wrong one and you either pay for streaming latency on a signal that changes daily, or you wire a daily batch under a use case that needed seconds.

This is the automation surface of Data 360, and it trips up teams precisely because the names don’t tell you the behavior. This post is what each of the four mechanisms actually is, how they fire, where they leak latency and credits, and a decision rule you can apply without guessing. If you’re still sorting out how the underlying signals are computed in the first place, our guide to calculated vs. streaming insights is the layer beneath this one — because which insight you built largely decides which automation you’re allowed to use.

Why Data 360 automation isn’t just record-triggered flows

The instinct, if you’ve built on the platform for a while, is to reach for a record-triggered flow. That instinct is half right and half a trap. A Data 360 signal is not a CRM record. It’s the output of unification and insight computation — a Data Model Object (DMO) row, or a Calculated Insight Object (CIO) result — that lives in the Data 360 lakehouse, not in your Sales or Service Cloud database. The automation surfaces that react to it inherit the lakehouse’s timing and semantics, and those are different from an sObject in ways that will bite you if you assume parity.

A Data 360 change is a signal about a customer, computed after the fact. CRM automation reacts to a record the moment a user saves it. Confusing the two is how teams build a “real-time” agent action on top of a batch that refreshes at 2 a.m.

Keep that framing and the four surfaces sort themselves into two axes: inside Salesforce vs. pushed to an external system, and near-real-time vs. scheduled/async. Everything below is a point on that grid.

Data Cloud-triggered flows: CRM-native, but post-commit and async

A Data Cloud-triggered flow is the closest thing to the record-triggered flow you already know. It’s an autolaunched flow subtype that runs when a DMO record changes or a Calculated Insight Object result changes and meets your entry conditions. Inside it you do ordinary platform work — create a Case, update a Task, enrich an account, call an invocable action. Salesforce documents it right alongside record-triggered and autolaunched flows, and it can create, update, and delete sObjects the same way.

Two things about it are not the same, and both matter.

It fires after the change is committed, and asynchronously. There’s no before-save, fast-field-update path here. The flow runs post-commit, more like an after-save flow, and because Data 360 ingestion and insight refresh are themselves batchy, the end-to-end lag from “the data changed in the real world” to “the flow ran” can be minutes, sometimes more. Practitioners who expected record-triggered immediacy have been surprised by the delay. If your downstream action is a human-paced follow-up, that’s fine. If a customer is waiting on the other end of it, it isn’t.

Prior-value semantics are weak. In a CRM record-triggered flow you lean on $Record__Prior to write “changed from X to Y” logic. On a DMO update trigger, prior values can come through as null, so change-detection logic that works flawlessly against an sObject misbehaves against a DMO. Design your entry conditions and decisions around the current value, not the delta, unless you’ve verified the prior value is actually populated for your object.

You can read Data 360 data from inside the flow, too. Since Winter ‘24 the Get Records element can query Data Cloud objects directly, provided the object has a DLO-to-DMO mapping, and you can pull Data 360 data through invocable actions. So a DMO change can trigger a flow that then reads more Data 360 context before it acts. Useful — but every one of those reads is a metered query, which we’ll come back to.

The catch nobody flags until they’re mid-build is testing. Flow Tests support record-triggered and Data Cloud-triggered flows, but they don’t cover asynchronous paths or delete triggers — which is exactly the mode a Data Cloud-triggered flow runs in — and those tests don’t count toward deployment coverage. Combine that with community reports of flows that silently don’t fire, and you get a surface you largely validate by watching debug logs in a sandbox rather than by writing a repeatable test. Plan for that. It’s a real gap next to the testing discipline you’d expect elsewhere on the platform.

Data Actions: near-real-time, external, and event-bus-indirect

A Data Action is the outbound-push primitive of Data 360. It’s most tightly coupled to Streaming Insights — the engine that evaluates events as they arrive inside a rolling time window — and it emits an alert to a Data Action Target in near-real-time when the data it watches changes. This is the surface you want when the signal is time-sensitive and the consumer is external or event-driven.

The documented targets are the ones that matter:

• Platform Event — publishes onto the core Salesforce event bus.
• Webhook — an event-driven HTTP POST to an external URL, with message integrity handled by a Salesforce-generated secret key so the receiver can verify the payload wasn’t forged.
• Marketing Cloud Engagement — drive an email or journey directly off a streaming event.

Here’s the part that confuses everyone, and it’s worth stating plainly: a Data Action does not “call” a flow. It publishes an event. If you want a flow to react, you point the Data Action at a Platform Event target, then subscribe to that platform event with a platform event-triggered flow. The Data Action is the publisher; your flow is the subscriber; the event bus is the seam between them.

Streaming Insight (cart quiet > 20 min, within window)
        │  emits
        ▼
Data Action  ──►  Platform Event target  ──►  core event bus
                                                   │  subscribed by
                                                   ▼
                                   Platform Event-Triggered Flow
                                   (create Case / notify agent / call service)

That indirection is a feature — it decouples the Data 360 side from the consuming side, and it lets a webhook go straight to an external system without any flow at all — but it’s also why teams mislabel the whole thing. There’s a reason the community keeps re-explaining Data Actions vs. activations: the mechanisms overlap in the mind and diverge in the runtime.

The trade you’re accepting with Data Actions is cost. Streaming operations carry the heaviest credit multipliers in Data 360 — dramatically higher per row than a batch query — so a chatty streaming insight firing data actions at volume can burn through credits far faster than a scheduled calculated insight would. That’s not a reason to avoid it; it’s a reason to reserve it for signals that genuinely need seconds, and to keep the streaming SQL lean. Our credit-optimization playbook exists for exactly this class of “I turned on streaming and the meter moved” surprise, and the pricing and credits guide is where the multipliers come from.

Activations and activation-triggered flows: the orchestration layer

The third surface is activation — the mechanism that publishes segment or DMO membership out to an activation target like Marketing Cloud, an ad platform, or an external system. Classic activation is scheduled and batch: build a segment, publish it on a cadence, let the target consume it. Cheap, high-throughput, and not remotely real-time. For audience-based marketing that’s the correct posture, and it’s a different job from the two surfaces above.

What’s new in 2026 is the activation-triggered flow — sometimes framed as flow-orchestrated activation — which turns an activation event into the start of a Flow. Instead of “publish the segment and hope a separate automation notices,” the segment publish or a Batch DMO activation becomes the flow’s start node, and from there you orchestrate: write to CRM, call REST endpoints, chain MuleSoft connectors to Marketo, HubSpot, NetSuite, an ERP, or a custom API — with clicks rather than a bespoke integration for each. There’s also a Send to Data 360 Activation flow action that performs an activation from inside a segment- or activation-triggered flow via API.

A couple of specifics worth knowing before you design around it: the entry segment for the orchestrated pattern is expected to use the Unified Individual membership type, you can branch on contact-point conditions (whether a known email, phone, or push token exists), and the sensible practice is to test against a small audience before you let it fan out. Treat this as an orchestration layer sitting on top of activation — not a low-latency path. If you need seconds, you’re back to Data Actions.

The decision rule

Strip away the names and it comes down to two questions: does the reaction live inside Salesforce or outside it, and how fast does it have to happen?

• Time-critical, external consumer (fraud signal, cart abandonment to an external system, a real-time nudge): Streaming Insight → Data Action, targeting a Webhook or a Platform Event. Accept the higher credit multiplier; keep the streaming logic tight.
• React inside Salesforce to a changed profile metric (create a Task, open a Case, enrich a record), minutes of latency acceptable: Data Cloud-triggered flow on the DMO or CIO change. Prefer this over a Data Action → Platform Event → flow chain when you don’t need the event bus and want to stay in one declarative surface.
• Segment or DMO membership must fan out to many systems with branching logic: activation-triggered / flow-orchestrated activation. This replaces the brittle “publish, then a separate automation reacts” design.
• The trigger is actually a CRM record, and the reaction is CRM-side: don’t route it through Data 360 at all. Use a record-triggered flow on the sObject. You get before-save speed, synchronous behavior, real prior-value comparison, and testable coverage. Reserve the Data 360 surfaces for signals that only exist after unification or insight computation — the ones a CRM trigger physically cannot see.

That last rule is the one teams break most often: routing an ordinary CRM reaction through Data 360 “because we have Data Cloud now,” and inheriting async latency, null prior values, and a testing gap for no benefit. If the signal lives in Sales or Service Cloud, react there. This is the same altitude question as our Flow, Apex, or Agentforce decision guide — the cheapest tool that fits the job usually wins.

Where these surfaces stop

• “Real-time” is relative, and mostly it’s minutes. Only the streaming/Data Action path is genuinely near-real-time. Data Cloud-triggered flows are post-commit and async; activations are scheduled. If a use case needs sub-second reaction and the signal is a batch calculated insight, no automation surface fixes that — the insight is the bottleneck, not the trigger.
• The event-bus hop is not free of failure modes. A Data Action → Platform Event → flow chain inherits platform-event delivery limits and the general reliability considerations of any event-driven integration. Design for the event you might miss, not just the one you’ll receive.
• Credits accrue on both the read and the reaction. A Data Cloud-triggered flow that calls Get Records against Data 360 is metering queries every run; a streaming insight firing data actions is metering the priciest operations in the platform continuously. Watch the Digital Wallet, not just the segment builder.
• Testing is thin on the async surfaces. You will validate Data Cloud-triggered flows with debug logs more than with repeatable tests. Bake that into your release process rather than discovering it at cutover.

What to actually do

Start from the signal, not the tool. Write down where the signal is born — a CRM save, a unified DMO row, a scheduled calculated insight, or a live event stream — and how fast the reaction has to happen. That pair almost always selects the surface for you: CRM-born and fast means a record-triggered flow; DMO/CIO-born and CRM-side means a Data Cloud-triggered flow; stream-born and external means a Data Action; membership-born and multi-system means an activation-triggered flow. Then price it: if the answer is streaming, confirm you actually need seconds, because you’re paying for them every row. Test what you can, log what you can’t, and keep the ordinary CRM reactions out of Data 360 where they don’t belong.

Get that mapping right and Data 360 stops being four confusing buttons and becomes what it should be — a governed layer that reacts to the signals only it can see, at the speed each one actually warrants, without you paying streaming prices for a daily batch. Whether you even need the paid Data 360 tier behind all of this is its own question, and we mapped it in does Agentforce need Data Cloud.

Understanding the basics

What triggers a Data Cloud-triggered flow?

A Data Cloud-triggered flow launches when a Data Model Object (DMO) record changes or a Calculated Insight Object (CIO) result changes and the change meets the flow’s entry conditions. It’s an autolaunched flow subtype that runs inside the Salesforce Platform — it can create, update, and delete CRM records and call actions — but it fires after the Data 360 change is committed and runs asynchronously, so it carries more latency than a CRM record-triggered flow and weaker prior-value semantics on updates.

What’s the difference between a Data Action and an activation in Data 360?

A Data Action is near-real-time and event-driven: usually fired by a Streaming Insight, it pushes an alert to a Data Action Target — a Platform Event, a Webhook, or Marketing Cloud — the moment data changes. An activation is scheduled and batch: it publishes segment or DMO membership to an activation target on a cadence. Data Actions are for time-sensitive, external, event-driven reactions and cost more per row; activations are for high-throughput audience delivery and are far cheaper. In 2026, activation-triggered flows add an orchestration layer on top of activation so a publish event can start a Flow.

Can a Data Action call a Flow directly?

Not directly. A Data Action publishes an event; it doesn’t invoke a flow. To make a flow react, point the Data Action at a Platform Event target and subscribe to that platform event with a platform event-triggered flow. The event bus sits between the Data Action and your automation. If the consumer is external rather than a flow, a Webhook target lets the Data Action POST straight to an endpoint with no flow involved.

---

Designing the automation layer over Data 360 and not sure whether your latency, your credit bill, or your silent-failure problem is the trigger, the insight, or the integration? Talk to us — wiring the right reaction to the right signal at the right speed is exactly the work we do.