Plan requirement
| Subscription | Suite Professional or higher, Explore Professional or higher |
| Access | Agent |
Custom fields are reportable, and how usable they are was decided when the field was designed.
Report on one
- Open a report on the ticket dataset.
- Find the custom field among the attributes.
- Add it as a grouping, or as a filter.
- Check how many tickets actually have a value.
Drop-downs report well
A fixed list of values groups cleanly. That is why a drop-down beats a text field for anything you will ever want to count, and it is a decision made when the field is created rather than when the report is.
Text fields do not
Free text produces as many values as there are tickets. You can display it; you cannot group by it in any useful way.
Where a text field is being used for something you now want to measure, the fix is a new drop-down going forward, not a clever report.
Check the fill rate first
A field completed on a fifth of tickets produces a report about that fifth. It looks authoritative and describes a minority.
Count tickets with and without a value before drawing any conclusion from the breakdown.
Optional fields skew
Where a field is optional, the tickets that have it are not a random sample: they are the ones somebody took the time on, which are usually the more complex cases.
Changing a field changes history
Renaming a drop-down value, or removing one, affects how old tickets report. Where trend data matters, add values rather than editing existing ones.
Fields on users and organisations
Those report too, and they are often more reliable than ticket fields because they are maintained centrally rather than filled in under time pressure.
Comments
0 comments
Article is closed for comments.