How we picked
Custom fields are where a helpdesk either bends to your process or forces you to bend to its. Every vendor claims support, so the claim is meaningless — what separates them is field types available, whether logic can drive visibility, whether the data flows through to reporting and the API, and whether you can model entities beyond the ticket at all.
We started with the reporting question because it's the one buyers discover too late. A platform that stores a hundred custom fields but only lets you filter reports on ten has given you a data entry burden and no analytical return. Agents notice this fast, stop filling the fields carefully, and within two quarters your custom schema is populated with defaults. Every pick here exposes custom field data to both the reporting layer and the API.
The second filter was conditional logic. Deep structured data and short forms are in direct tension, and conditional fields are the only real resolution. A form that asks three questions and reveals the fourth based on the third gets better data than a twenty-field form that agents skim. Tools without conditional logic push teams toward multiple ticket types instead, which fragments reporting.
Third, we separated field customization from entity modeling. Teams that need to track contracts, devices, sites, or licenses alongside tickets don't need more fields — they need custom objects with relationships. Halo, Vivantio, and Wavity handle this; stapling site_name onto every ticket as a text field is the workaround you're trying to escape.
What to prioritize
- Prove reportability with one field before you design the schema. Create it, populate it, filter a report on it, and read it from the API. If any step fails, stop designing.
- Conditional visibility driven by earlier answers. This is what lets you collect deep structured data on a form agents don't resent. Without it, expect field fatigue and default-value pollution.
- The right field types, not just text. Date, currency, multi-select, lookup to another record, and computed fields each remove a class of manual work. Free-text fields where a picklist belongs destroy reporting.
- Field-level permissions if anything is sensitive. Cost codes, security classifications, and HR data need role-based visibility, not just a restricted queue.
- Custom objects when you're modeling entities. Repeating the same three fields on every ticket is the symptom. Contracts, assets, and sites want to be records with relationships.
- A field lifecycle plan. Custom schemas rot. Decide who owns changes, require a stated report or automation for each new field, and run a quarterly audit that deletes fields nothing queries.