#Data Cloud76 discussing

Yes, this is possible, but the approach differs depending on whether you’re using Marketing Cloud Engagement (SFMC) or Marketing Cloud Next.

If you’re using Marketing Cloud Engagement:

For MobilePush:

Data Cloud DMO → Create/Publish Segment → Activate to Marketing Cloud → Map the required contact/device identifiers → Create the MobilePush message → Use Journey Builder to send/orchestrate the push notification.

Make sure the mobile app is configured with the Marketing Cloud SDK and that device/contact registration and consent are available.

For WhatsApp:

Data Cloud DMO → Create/Publish Segment → Activate to Marketing Cloud → Map the subscriber/contact identifier → Configure the WhatsApp channel and approved message templates → Use Journey Builder to orchestrate the WhatsApp communication.

WhatsApp consent/opt-in and the appropriate phone-number identity mapping are important here.

If you’re using Marketing Cloud Next:

The pattern is more Data Cloud-native:

DMO/Data Cloud data → Create Segment/Audience → Configure the required channel and identity/consent data → Create the message/content → Build the campaign/flow → Activate through the supported Mobile or WhatsApp channel.

So, in both cases, the DMO is essentially your data foundation. You don’t send MobilePush or WhatsApp directly “from the DMO.” You use the DMO data for segmentation and activation, while the actual delivery happens through the configured messaging channel.

If the Contact record can be reliably matched back to the Calculated Insight using the Contact ID or another stable key, I’d lean toward handling the bulk update through a Flow rather than maintaining separate logic for individual records.  

The one-off Data Cloud-triggered Flow seems fine for testing, but for 20K+ Contacts I’d first make sure the matching relationship is consistent and then test the bulk update with a small batch before running it across the full dataset. That should also make it easier to troubleshoot if some records don’t have a corresponding insight value 

Hi Marko - the reason you can't use a Zero Copy data lake object in a Streaming Data Transform is architectural, not a config gap, and it points straight at the fix. 

Streaming Data Transform works on data as it's streamed/ingested INTO Data Cloud in real time (the real-time ingestion channels - Web/Mobile SDK, Server-to-Server / Ingestion API). Zero Copy data is federated: it stays in the external source (Snowflake/BigQuery/etc.) and is queried on demand - it never actually streams into Data Cloud as events. So there's no incoming stream for a Streaming Data Transform to act on, which is exactly why the zero-copy DLO isn't selectable as a streaming source and the mapping isn't available. 

So for zero-copy consent data, Batch Data Transform is the correct/supported path - what you're already doing. To handle the cost and latency: 

- Incremental batch: if you can key the transform to only changed rows (a watermark / incremental load) instead of reprocessing everything hourly, you cut credit consumption a lot - and tune the frequency to what consent actually needs. 

- If you need true real-time consent (especially honoring opt-outs immediately): change the ingestion method for the consent signal from Zero Copy to streaming ingestion. Push consent changes into Data Cloud via the Ingestion API (streaming) or a streaming connector so they land as ingested/streamed data - which a Streaming Data Transform CAN then process into the Comm Subscription Consent object in near real time (streamed data processes asynchronously, roughly every few minutes). Keep zero-copy for the bulk/at-rest data and add a streaming feed just for the real-time consent updates - a hybrid. 

That hybrid (zero-copy for federated data + streaming ingestion for the signals you must act on instantly) is the standard pattern when a use case needs both. One note: the real-time path is streaming-only - bulk isn't supported for real-time ingestion - so the consent feed would need to come through a streaming channel. 

Refs: 

- Real-Time Ingestion and Actions in Data Cloud:

- Transform Data in Near Real Time (Streaming Data Transforms):

Great write-up of the dependency chain, and your last hypothesis is essentially right. Here is how these pieces actually deploy: 

1) Supported approach for the Data Cloud foundation. 

The Deploy Data Kit Components flow (or the Data Kit Publishing Sequence) is the supported way to move the core Data 360 objects. It deploys components sequentially in dependency order and waits for each component to finish before starting the next (requires REST API v61.0 or later). That covers Data Stream Bundles, Data Lake and Model Objects, Data Transforms, Calculated Insights, Data Graphs, Identity Resolution, and Segments. 

2) The key catch: Retrievers, Search Indexes, and Prompt Templates are not standard Data Kit content. 

They are not in the Data Kit deployable-component list, so they do not travel with the Data Stream or Model bundle. What is packageable is governed by the Data 360 Extensibility Readiness Matrix (linked on that same dev-guide page), so check it for the current status of Search Indexes and Retrievers. Prompt Templates deploy as their own metadata (GenAiPromptTemplate) through the Metadata API, packages, or change sets, separate from the Data Kit. 

3) Do the dependencies need to exist first? Yes. 

Your chain (Data Source, Data Streams, DMOs, Search Indexes, Retrievers, Prompt Template) has to be fully deployed and provisioned in the target before the Prompt Template validates: DMOs mapped, Search Indexes actually built, and Retrievers present and describable. Deploying the Prompt Template in the same pass as its retrievers is the risky part, because the template resolves its retriever references at deploy time. 

4) The describe-data-provider error. 

That lines up with what you suspected: when the Prompt Template (or the retriever it points to) is validated, its underlying data provider (the DMO, Search Index, or Retriever) is not resolvable yet in the target org, so the platform cannot describe it. Sequencing fixes it. 

Recommended sequence: 

1. Deploy the Data Cloud foundation via the Data Kit flow (streams, DMOs, mappings) and let it finish. 

2. Create or verify the Search Indexes and Retrievers in the target and confirm they are active and queryable (rebuild indexes if needed). 

3. Deploy the Prompt Template last, once its retrievers describe cleanly. 

Reference: "Deploy Data Kit Components" in the Data 360 Developer Guide (

Hi Hemanth, 

This is a common one, and the symptom you're describing — SSC populating while SSPC stays at zero — almost always points to mapping rather than the event itself. Since your SSC records are landing, the event is firing fine. 

The key thing: cart and order engagement events don't get their own data streams. They're consolidated into a single Behavioral Events stream, and the DLO that gets auto-created has to be mapped to each target DMO separately. So on the DMO side of the mapping canvas you need Shopping Cart Product Engagement added as its own target, alongside Shopping Cart Engagement. If only SSC was added, SSC fills and SSPC stays empty — exactly what you're seeing. 

Four things worth checking, in order: 

1. Primary key. eventId has to be mapped to the primary key of every DMO, not just the first one. For SSPC that's ssot__Id__c. If it's unmapped, nothing lands — and as a side effect your Data Transform will run full instead of incremental, which also costs more. 

2. The relationship back to the cart. SSPC is Many-to-One to Shopping Cart Engagement via ssot__ShoppingCartEngagementId__c. If that's not mapped, the line items have nothing to attach to. 

3. Product-level fields in the payload. SSPC expects ssot__ProductId__c, and usually ssot__ProductSKUnumber__c, ssot__ProductQuantity__c and ssot__ProductPrice__c. Worth confirming your cart event is actually sending a line-item array and not just cart-level totals — if the products array isn't in the payload, there's nothing to map. 

4. Validate the mappings. Setup → Marketing Features → Triggers management page checks whether your DMO mappings are configured correctly and surfaces errors. Clear everything there before troubleshooting further, then let the transform re-run. 

To your questions directly: 

SSPC records are created when the behavioral event carries product line-item data and the DLO is mapped to the SSPC DMO with both the primary key and the cart reference mapped. Yes, it needs configuration beyond SSC — same data stream, separate DMO mapping. And yes, SSC-populated-but-SSPC-empty is a very typical outcome of mapping only the cart-level DMO. 

Hope that helps — let me know what the Triggers page shows. 

Hi @Omar Kharrat

, 

Here is what you can try: 

1. Build a custom DLO/DMO that's a

2. Instead of segmenting on Individual or Unified Individual, set "Segment On" to that fan-out DMO. 

3. Now every row in your segment membership is a contact point, not a person — so when you activate, the output has one row per email address. 

4. Use an Activation Template here, since it lets you tie the specific contact point to the record without invoking identity resolution at all. With Activation Templates, the Contact Point to use is tied to the Individual or Engagement record, without any Identity Resolution needed.  

I haven't run this exact "3 emails per individual" scenario end-to-end myself yet, so treat it as an architecture direction to prototype rather than a guaranteed fix. 

For more details, you can refer this: