Plan requirement
| Subscription | Suite Professional or higher, Explore Professional or higher |
| Access | Agent |
Where each field type lands in Explore, why a new one is not there yet, and the dataset that holds the change history you thought you had lost.
Report on one
- Open a report on the ticket dataset.
- Find the field in the folder its type belongs to, not by searching blindly.
- Add it as a grouping, or as a filter.
- Check how many tickets have a value before you read anything into the breakdown.
Which folder your field is in
| Drop-down, multi-select, text, multi-line, checkbox, credit card, regex | Attribute, in Ticket custom fields, Requester/User custom fields or Requester/User organization custom fields |
| Date | Attribute, with several time dimensions in a folder of its own |
| Numeric and decimal | Metric, in Numeric custom fields |
| Lookup relationship | Only on standard objects. A lookup field on a custom object cannot be reported on |
Watch which folder you take it from: the same field name can appear under both Ticket custom fields and Requester/User custom fields, and the two return different values. And two custom fields sharing a name cause trouble in formulas, so it is worth not having any.
Two datasets carry no custom fields at all: Support - Backlog history and Support - Group SLAs.
Why a new field is not there yet
Custom fields synchronise with Explore every hour, and a newly created or reactivated field appears at the next sync, which can take one to two hours. On top of that, the values have to have been used on real tickets, users or organisations before they show up.
Deactivating a field in Support removes it from new reports but leaves it working on existing ones. Renaming a field or a value follows through to Explore.
Only the latest value is kept
The standard metrics and attributes hold the current value of a field and nothing else, so a report on them cannot tell you what a field used to say. The Updates history dataset does, through its Changes attributes.
That is also the honest answer to renaming: a renamed drop-down value rewrites how old tickets report, so where trend data matters, add values rather than editing the ones you have.
The field design decides the report
A drop-down groups cleanly because it has a fixed list. Free text produces as many values as there are tickets: you can display it, you cannot group by it usefully, and the fix is a new drop-down going forward rather than 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 a conclusion.
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.
User and organisation fields are often better
They report too, and they tend to be 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.