#Data Cloud69 debatiendo

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.

Hi @David Loyola

Try this: Set up a Data Action on your Calculated Insight that triggers a Flow, and have that Flow update the matching Contact records. The Copy Field feature your vendor mentioned as the alternative is more rigid and is exactly why they suggested cloning the CIs, you'd be duplicating work to fit that feature's constraints. The Data Action to Flow path avoids that entirely. 

Since you have 20K+ Contact updates, that will hit Flow and DML governor limits if it fires per-record. Make sure the Flow is built to batch rather than update one Contact at a time, or route it through a bulk-friendly pattern. Also, confirm that your Calculated Insight has a dimension that maps cleanly to a Contact identifier, because that mapping is what makes the write-back resolve to the right records.

@Sourabh Dondekar

:  Data Cloud uses the static exchange rates and currency codes defined in your CRM org for processes like data transforms, segmentation, and calculated insights.  

In a single-currency organization, Data Cloud syncs its currency data from your Salesforce org via DLO named Static_Currency_Rates_<CRM orgID>. This gets synced automatically, so you can check if you see your desired details in this DLO. If not, this is where we need to focus. 

In a multiple-currency organization, Salesforce creates a data stream named Static_CurrencyType_<CRM orgID>. Each CRM org manages its own currencies and conversion rates. Here you can check if the number of records (i.e. currencies) are same in both DLOs. If not, this is what we shall focus.  

More details are here:

Please check, and let me know of these, then we shall be able to explore this further.