#Data Cloud73 人正在讨论

@Matt Thomas

I have a few final considerations, if you could help me:  

1 - When you mention "product", are you referring to the Product Catalog DMO or Shopping Cart Product Engagement? 

2- Do we need to create a relationship linking Shopping Cart Product Engagement to the Product DMO?

3- Individual > Shopping Cart Engagement > Shopping Cart Product Engagement > Product. Is this the expected structure? Or does there need to be a direct relationship between Product and Individual? Can it be indirect?

Hi @Galla Rajeswari Good question! Data 360 is not just about combining data. It helps businesses use customer data more effectively.

1. Identity Resolution: Combines customer records to create a unified customer profile.
2. Data Graphs: Connect related data and help Agentforce access customer information faster.
3. Segmentation: Helps businesses identify and target the right customers.
4. Real-Time Activation: Helps businesses take action using updated customer data.
5. Agentforce: Provides better customer context, helping agents give more relevant and accurate responses.

In my view, Identity Resolution and Data Graphs are especially useful for Agentforce.

Key Point: Data 360 provides the right customer context, while Agentforce uses that data to answer questions and perform actions.

@Saurabh Singh

It seems the index configuration was completed at the metadata level, but the underlying chunk table was never physically created or materialised.  

Try below -  

Delete and recreate the Search Index rather than querying the chunk table directly. The chunk DMO isn’t meant to be hand-queried in Data Explorer as your primary check anyway, recreating forces the chunk table to rebuild. Confirm the source DMO has rows first. 

Verify the source DMO (KnowledgeArticleVersion__dlm) is populated and mapped before rebuilding. No source content, no chunk table. 

Since this is a vector/Search Index feature that’s still maturing in Data Cloud, if the source has data and a clean rebuild still leaves the chunk table missing, treat it as a platform provisioning issue and raise a case with the TraceId from your error (33aa86a19608e2b0). That TraceId lets Salesforce pull the exact failure in the chunking/embedding job server-side, which is the one thing none of us can see from the UI, the Ready status is hiding whatever actually failed underneath. 

Hi @Ionuț Buzatu

, 

This is probably not a broken Data Kit. A Data Kit carries the design (streams, mappings, Identity Resolution, Data Graphs), but not the connections or the source data

. 

Why it fails:

• Marketing Cloud streams: the connector is linked to a specific Marketing Cloud account and business unit, and credentials do not deploy. If Test is not connected to a matching account, the streams cannot be created. Identity Resolution and Data Graphs then fail because they depend on those streams.
• CRM streams with missing fields: a stream can only include fields that already exist in the target org. If the custom objects and fields (and field-level security) were not deployed to Test first, they are left out.

What to try:

1. Deploy the CRM metadata (objects, fields, FLS) to Test first.
2. Set up and authorize both connectors in Test manually.
3. Deploy in order: CRM streams, then Marketing Cloud streams, then Identity Resolution, then Data Graphs.
4. Check Setup → Deployment Status for the real error behind the generic message.
5. If it still fails, open a Support case with the Data Kit name, the failing component and the deployment Id.

 Hope this helps. If it solves the problem, please mark it as the best answer. And if you find the real cause, please share it, so other people with the same issue can use it. 

@Liliana Camargo that crawler reads the HTML the server returns. It does not run the page JavaScript, so a section that only exists after the browser executes a script is not in the fetch. That is a limitation of the connector, not a setting you missed.

The reliable fix is to put that content in the first HTML response. Server-side render it, or give the crawler a prerendered URL. If the site already has an API, a CMS export, or a PDF, ingest that instead of the rendered page.

I would not keep tuning the crawler and hoping it executes the script. It will not.

@Clinton Fernandes

From an architecture perspective, I’d separate record access, field visibility, and reporting permissions. Salesforce FLS applies across the platform, so allowing users to read financial fields on Account also has implications for reports and list views.

I’d start with least-privilege access, report folder permissions, and restrictions on report creation and data export. If the requirement is to hide the same fields in reports while retaining record-level visibility, standard configuration has limitations, and a custom UI may be worth evaluating for specific use cases.

Hi @Mounika Aithagoni

You would decide based on these core points:

1. Data Ingestion: Best for data transformation, identity resolution, and unified customer profiles.
2. Zero Copy: Best for accessing large external datasets without duplicating data.
3. Real-Time Data: Zero Copy with live queries can provide access to the latest source data.
4. Performance: Ingestion is useful for frequently processed data. Zero Copy depends on external query performance.
5. Cost: Compare ingestion and storage costs against Zero Copy query costs.
6. Security: Consider data governance, access permissions, and compliance.

My suggestion: Use a hybrid approach based on business requirements. Always validate performance, data freshness, and cost through a POC before finalizing.

Hello @Antonio Bianco Ignacio

You can try the following options:

•  Clear the browser cache -> log out & log in again, then check the challenge
•  Check your challenge in incognito mode/Private Window or a different browser. 
•  If you still face the same error, delete and recreate it again, then try to check your challenge, or I recommend that you create a new playground and complete this task there.
•  https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000C4t16SAB
•  https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000JeMjKSAV

Hi Venkata, 

Best answer to your core ask: use Data Cloud's native Writeback feature (a Batch Transform/Data Transform with a Salesforce Object as the target), not a scheduled Flow. This directly solves your problem — it reads the entire DMO (all existing + new records) on a schedule, writes to CRM via Upsert matched on your key field (account_id), and isn't triggered by create/update events at all, so backfill and ongoing sync use the exact same mechanism. 

How to set it up: 

1. Data Cloud → Data Transforms → create a Batch Transform (or use an existing one) sourced from your DMO 

2. In the Writeback/target configuration: Target Type = Salesforce Object, select your account_data custom object 

3. Action Type = Upsert, map account_id as the matching key, map your other fields (e.g., model) 

4. Schedule the transform to run as often as needed (this is a genuine scheduled batch job on Data Cloud's side, not something bound by Flow governor limits) 

This directly answers your numbered questions: 

1. Recommended way: Writeback via Data Transform (above), not a flow-based approach, for anything beyond small volumes. 

2. Copy Field enrichment: works, but it's designed for real-time, per-record enrichment onto existing CRM records as they're viewed/queried — not a backfill mechanism for records that already exist and won't re-trigger. Not the right tool for "sync everything now." 

3. Scheduled Flow reading DMO at scale: it'll work for low volume, but Flow's Get Records/Update Records has standard governor limits (SOQL rows, DML rows per transaction) — it's not built for bulk DMO-to-CRM sync the way a Data Transform writeback is. Expect it to struggle or need batching logic once you're past a few thousand records. 

4. Correct — Copy Field enrichment is standard-objects-only. But Writeback via Data Transform is not restricted that way: Salesforce Object as Target Object explicitly supports custom objects, which is exactly your account_data case. 

For the one-time backfill specifically: you don't need Data Loader as a separate step — just run the Writeback transform once manually (on demand) for the backfill, then put it on a schedule for ongoing sync. Same mechanism handles both. 

Reference: