Issue with Deploying the Data kit Via Change sets

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.