Plan requirement
| Subscription | Any plan |
| Access | Admin |
Every field type in Zendesk, what it is genuinely for, and the three that people reach for and later regret.
The types
| Type | Use it for |
|---|---|
| Drop-down | One choice from a fixed list. The workhorse, and the only type you can report on cleanly. |
| Multi-select | Several choices at once. Harder to report on than it looks. |
| Text | A short free value such as an order number. |
| Multi-line | Longer free text. |
| Numeric | Whole numbers. |
| Decimal | Numbers with fractions, such as an amount. |
| Checkbox | A yes or no that adds a tag when ticked. |
| Date | A date. Business rules can compare against it. |
| Regex | Text that must match a pattern, such as a postcode. |
| Credit card | A payment card number, stored masked. Only where you genuinely need it. |
| Lookup relationship | A pointer to a user, organisation, another ticket or a custom object record. |
| Multiple lookup | Several records of one object linked to one ticket, such as a ticket to several products. |
The three people regret
Text where a drop-down belonged
Free text cannot be reported on usefully. Twelve agents typing the same category produce twelve spellings. If you will ever want to count it, make it a drop-down.
Multi-select used as a category
Multi-select is right for genuine multiples, such as affected products. It is wrong as a way of avoiding the decision about a primary category, and every report on it needs care to avoid double counting.
Checkbox where a drop-down belonged
A checkbox has two states and no third. As soon as you need "yes, no, not applicable" you need a drop-down, and converting later means fixing history.
Drop-down values are hard to change later
Renaming a value affects existing tickets and any rule referring to it. Deleting one leaves old tickets pointing at nothing. Settle the list before you deploy, and add rather than rename where you can.
Comments
0 comments
Article is closed for comments.