#Data Cloud72 人正在讨论

Thank you, @Liza Daniel

. I've implemented the Data Cloud-Triggered Flow and it appears to be working for the one-off update cases when the Contact ID exists in the CRM. 

Are you familiar with bulk updates using the Platform Event-Triggered Flow? I've setup the Data Activation Target and Data Action, but familiar with the build of the flow. My object is to search for all values in the CI and update the corresponding Contact records with a value for now.

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):

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.

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:

@Marcos Gomes

In my opinion, governance should come before autonomy. Agentforce is only as reliable as the data and permissions it is given.

A practical approach is:

• Clean legacy data first by removing duplicates, standardizing values, archiving obsolete records, and defining data quality rules.
• Implement strong data governance with clear ownership, validation rules, monitoring, and regular data quality reviews.
• Apply least-privilege access so AI agents only access the data they genuinely need. Sensitive fields should be protected with Field-Level Security, Permission Sets, Shield Platform Encryption, and Data Cloud data policies where applicable.
• Establish trust boundaries. Don't allow autonomous agents to perform high-risk actions without human approval. Critical decisions (pricing, financial updates, customer record changes, etc.) should include approval workflows or human-in-the-loop checkpoints.
• Continuously monitor and audit agent activity using logs, event monitoring, and feedback loops to identify incorrect decisions and improve prompts, policies, or data quality.

Ultimately, successful Agentforce implementations depend less on the AI model itself and more on the organization's data quality, governance framework, and security controls. Clean, governed, and well-permissioned data is what enables AI agents to make trustworthy decisions.