* Data 360 *

Hey Swetha, 

Per Salesforce's own developer blog, consent should be your first suspect, "without a recorded opt-in for the relevant purpose, the SDK will suppress downstream event tracking, which looks identical to a broken sitemap or schema. Always validate that consent is firing before you start debugging anything else." Your consent block looks correctly structured, but confirm in browser DevTools > Application > Cookies that the consent cookie is actually getting set after page load, not just that the script ran without errors. 

Second likely issue: your initSitemap call has an empty pageTypes array: `SalesforceInteractions.initSitemap({ pageTypes: [] })`. Per Salesforce's Interactions SDK docs, the sitemap needs at least one page type configuration to actually match and dispatch events, an empty array means there's nothing for the sitemap to match against, so events likely aren't being triggered at all even though the SDK itself initializes fine. 

Debugging steps directly from Salesforce's own guide: 

1. Enable debug logging (there should be a way to set a debug log level in the SDK init options) 

2. Look for the [DEBUG]: Sent event and [DEBUG]: Sending events console messages, if these never appear, the event is never being generated client-side (points to consent or sitemap config) 

3. Also listen for the OnPageMatchStatusUpdated custom event, this shows exactly how the sitemap's page-type matching evaluated, useful specifically because you have an empty pageTypes array 

Given your embed code matches the Medium article closely, but that article was written for a CloudPages/Marketing Cloud context, if you're implementing this on an external developer website (not a CloudPages-hosted page), double check the wtcp_id and connector match exactly what Data Cloud generated for you, a mismatch there would also cause silent non-tracking. 

Reference:

Hi Chinmai, 

Two things going on here, and the second one is probably the more useful. 

On the error itself: "invalid at this location in type" is the metadata parser in the target org encountering an element it doesn't recognise. In your case that's isSqlDmo inside MktDataModelAttributes — production is reading the file and finding an attribute its schema doesn't know about. That almost always means the source and target orgs aren't aligned: either UAT is on a newer release than production (very common if UAT is a preview sandbox during a release window), or the DMO schemas themselves differ between the two orgs. 

Worth checking first: compare the release version of both orgs, and compare the DLO and DMO field definitions for the object involved. Salesforce's own guidance on data kit deployment failures is that schema differences between source and target need resolving before you deploy, not during — so if production has fields the source doesn't, or vice versa, synchronise those first. 

The second thing, and I'd look at this before spending much longer on the error: there are two kinds of data kit, and only one of them is meant for change sets. The UI-oriented data kit supports manual change set deployment. The DevOps Data Kit is designed for CLI-based deployment across Dev, QA, UAT and Prod — that's the whole point of it, and it's how Salesforce documents deploying it. 

So if what you have is genuinely a DevOps Data Kit, change sets may not be a supported path at all, and the parsing error is a symptom of pushing it through a mechanism it wasn't built for rather than something you can fix in the change set. 

The reference worth reading is "Use CLI to Deploy Changes from a Sandbox to Data 360" in the Data 360 Developer Guide. It has a troubleshooting section covering data kit deployment failures specifically — including schema mismatches and cases where the fix is to locate and remove the offending XML files from the SFDX project before redeploying. That pattern may well apply to yours. 

One honest caveat: I'm reasoning about isSqlDmo from the shape of the error rather than from documentation on that specific attribute, so treat the diagnosis as a strong hypothesis rather than a certainty. If you switch to the CLI path and still hit it, that's worth a case — an auto-generated data kit producing metadata the target can't parse isn't something you should have to work around. 

Let me know what the release versions show. 

Hi @Ayo Obajuluwa

, thank you for the reply. We have a similar issue and have received conflicting advice from Salesforce Support. We have a working perm set for our Employee agent to access the Knowledge ADL using the Data Cloud Data Space Management section in the perm set. 

However, more recently, SFDC support said we should be using Data Governance within D360 to set these "allow" access permissions. Do you have an example of how we would set that up? I've created a Tag Taxonomy for Knowledge Access and an accompanying Internal tag for Knowledge, but when I click on the Content Tagging Settings, it says those are in Beta which wouldn't be an option for our Prod deployment. 

Thanks in advance, Bill

Hi Johan, 

The useful thing in what you've posted is that the pipeline completes cleanly and only the retrieval fails. That tells you the ingestion and indexing are fine and the problem is entirely in the generated retriever query — which narrows it considerably. 

The standard ADL retriever joins the chunk table to ssot__KnowledgeArticleVersion__dlm aliased as "kav", matching "c"."SourceRecordId__c" to "kav"."ssot__Id__c". That's the only field it needs from that DMO. Your generated query is additionally reaching for "kav"."ssot__MasterVersionId__c", which is what the Data Category variant requires — because data categories are assigned at the master article level rather than per version, so the query has to resolve the version back to its master before it can filter on category. 

So the question is whether that field exists and is populated in your org. 

Check this first: Data Cloud Setup, Data Model, open the Knowledge Article Version DMO and look for ssot__MasterVersionId__c. Two possible outcomes. 

If the field exists but is unmapped, that's your answer. Go to the Knowledge data stream, confirm MasterVersionId is included in the source fields, and map it to ssot__MasterVersionId__c on the DMO. Then refresh the data stream and let the transform complete before retesting. An unmapped field will still show in the schema but the Query Editor will reject it exactly as you're seeing, because there's no underlying column materialised. 

If the field isn't present in the DMO schema at all, then the generated query is referencing something your org's data model doesn't have. At that point I'd rebuild the Data Library from scratch rather than debug further — the retriever query template for Data Libraries changed within the last year, and an ADL created before that change can carry a stale generated query. Recreating forces the retriever to regenerate against the current template and current schema. 

If you rebuild and still get the same missing column, I'd log a case and include the generated query text alongside the Query Editor error. That combination — an auto-generated retriever referencing a column that doesn't exist in the DMO it's querying — isn't something you can configure your way out of, and it's the kind of thing support can confirm quickly. 

One smaller thing worth ruling out while you're in there: confirm the agent user has access to the data space the library sits in. That surfaces as a different error, so it's probably not your issue, but it's cheap to verify. 

Curious what the DMO shows — post back and I'll have another look.