When Dataverse forms don’t validate: the XSD gap in Microsoft’s standard definitions

If you’ve ever trusted the XSD to validate your customizations — you might want to read this.

Last week, I was playing around with my MCP server to improve its reasoning capabilities — specifically around Dataverse form structures.

One of the goals was to make it more reliable and less prone to hallucinations when generating or modifying FormXML definitions.

As part of the process, I added a validation step to check whether generated forms complied with the official FormXML XSD schema published by Microsoft.

What I didn’t expect?

Even Microsoft’s own out-of-the-box forms don’t pass the test.

🔍 Validation Results

📦 Environment 1: Clean Sandbox

Dataverse version: 9.2.25063.192
Installed apps: Only base Dynamics app (no Sales, Customer Service, or Field Service)
Forms analyzed: 258
Invalid forms: 22 (~9%)
Issue:
- All failing forms are of type Main
- All fail for the same reason:
```
The 'headerdensity' attribute is not declared.
```

🧪 Environment 2: Sandbox with Dynamics 365 Sales + Customer Service

Dataverse version: 9.2.25063.192
Installed apps: Dynamics 365 Sales and Customer Service
Forms analyzed: 1,462
Invalid forms: 307 (~21%)
Issues:
- Multiple undeclared attributes:
- 'headerdensity'
- 'showinformselector'
- 'showcommandbar'
- 'showbody'
- 'showtabnavigator'
- 'contenttype'
- 'visible'
- Invalid child elements in the <parameters> block:
- UClientActivitiesConfigurationJSON
- UClientEnableWhatsNewFilter
- ...and others not listed in the schema

These attributes and elements are not declared in the official XSD, making the form definitions technically invalid — despite being first-party forms built into Microsoft’s applications.

⚠️ Why Does This Matter?

If you rely on XSD validation in CI/CD pipelines, tools, or custom dev workflows, you may be rejecting valid forms.
The schema appears outdated or incomplete, diverging from what’s actually generated by the Dataverse platform.
Developers and platform engineers might need to patch the XSD or implement more tolerant validators to handle real-world metadata.

🧠 Final Thoughts

This isn’t necessarily a bug — but it does show how platform metadata and published standards can drift apart over time: the Official Web Page last update was on feb 2022, and the version number of the schema was 9.0.0.2090, while the environments where I did the test were both on 9.2.25063.192.

It’s a useful reminder for anyone building automation or tools on Dataverse:

Trust the docs, but test the data. Always.

If you're interested on the details of the validation, drop a comment below and I will post the results.

📚 References

🧪 Appendix: Beyond XSD — Custom Structural Rules in FormEngineer MCP Server

While refining validation logic for the next version of my MCP server, I also noticed a recurring issue unrelated to the XSD schema but still important for proper form layout.

In several forms — including those generated by AI — some sections contained rows with inconsistent numbers of populated columns. For example:

One row with 3 fields,
Another with 2,
Then one with 4...

All within the same section.

In well-structured forms, once a section is defined with a certain number of rows and columns, each cell in the grid should be intentionally filled, either with a field or an empty placeholder.

This "rule" is based on layout consistency and usability, and while it cannot be enforced via XSD validation, it has now been integrated into a custom logic layer in my MCP server to ensure better visual coherence in form generation.

📌 Note: These additional checks are not part of the XSD validation described in the main body of the article — but they highlight some of the improvements coming in the next version of the server.

Stay tuned!