Editorial illustration.
Originally published 22 June 2023; rewritten and reviewed on 15 October 2026.
A custom feature needs to know which fields belong to a Kentico class. Hard-coding a second list looks quick, but the two definitions can drift as editors change the form. I would first inspect the metadata already maintained by the CMS.
Distinguish a definition from a record
A form definition describes fields, types and configuration. It is not a submission and does not establish that the current user may read the submitted values. Keep metadata inspection separate from access to business data.
In older Kentico/Xperience projects, APIs such as DataClassInfoProvider and FormInfo provide the vocabulary for this work. Exact construction and lookup methods vary by version, so use the API reference shipped with the application rather than mixing examples from different releases.
Resolve the intended class by its stable code name
→ Handle an unknown or unavailable class
→ Parse its supported form-definition representation
→ Read only the field metadata the feature requires
→ Apply the result within the caller's permissions
The outline keeps version-dependent calls in one small adapter. That is easier to update than spreading assumptions about the CMS schema across several pages.
Avoid making internal metadata public by accident
A diagnostic endpoint that returns every class and field can reveal more about the application than intended. Restrict the operation to an appropriate administrative context and return only the information needed for the feature.
Check changes to the definition
Test an absent class, a field added by an editor and an unexpected field type. If the feature caches metadata, define how a form change invalidates that cache.
The useful result is a custom behaviour that follows the CMS definition while remaining explicit about the few field types and settings it actually understands.