Zendesk Custom Ticket Fields
A Zendesk custom field is the cheapest structure you can add to a helpdesk, and the easiest to add too much of. Here's what each type is genuinely for.
Zendesk custom field types, and what each is for
:: give you categories without extra fields.Fields belong to the account, forms decide where they appear
This trips up nearly everyone at first. A custom field is created once, for the whole account. A ticket form is a selection and ordering of those fields.
So the same "Order number" field appears on your Returns form and your Billing form, and it's one field with one id and one report. Create a second order-number field for the second form and you have split your data forever.
Fields can be marked required on a per form basis, and their position differs per form. That combination is what lets one field library serve six teams. Pair it with conditional fields and a thirty-field form can feel like a four-field one.
Required to submit versus required to solve
Two different settings, and picking the wrong one is the single most common field mistake.
Required for end users means the customer cannot submit the form without it. Use this sparingly. Every required field on a customer-facing form is a small tax on getting help, and a customer who abandons the form emails you instead, usually twice.
Required for agents to solve is the good one. The ticket flows freely, the agent triages, and the categorisation is enforced at the moment the agent already knows the answer. That's when the data is accurate anyway.
If you want clean reporting, put almost nothing on the customer form and make the categorisation required on solve.
The field ID problem
Every custom field has a numeric id, and the API speaks entirely in ids. Titles don't appear in the payload at all. Which means every script anybody writes starts with someone pasting a ten-digit number into a constant, and nobody remembers which is which six months later.
Pull the map instead of memorising it.
curl -s -u you@example.com/token:APITOKEN \
https://acme.zendesk.com/api/v2/ticket_fields.json \
| jq -r ".ticket_fields[] | [.id, .type, .title] | @tsv"That gives you id, type and title for everything on the account. Two ways to use it.
Small scripts: resolve the ids once at startup by title, cache them, and fail loudly if a title is missing. Anything bigger: keep a checked-in config file mapping a stable internal name to the id per environment, since your sandbox has completely different ids from production and that is the bug you'll actually hit.
Never match on title at runtime for anything critical. Someone will rename "Order number" to "Order Number" and your integration will start writing nulls.
Housekeeping
Three habits, and they take about an hour a year between them.
Deactivate, don't delete. Deleting a field takes its values with it, so every historic ticket loses that data and every report changes shape. A deactivated field keeps its history and stops appearing on forms, which is what you actually wanted.
Prune the drop-down options once a year. Options that have not been picked in twelve months are noise, and the list length is what makes agents pick the first plausible entry rather than the right one.
And keep the count down. Twelve well-chosen fields beat forty aspirational ones, because agents fill in twelve. Every field you add is a small tax paid on every ticket for the rest of the account life, and the ones added "so we can report on it later" are almost never reported on. If you can't name the chart a field will appear in, you do not need the field yet.
Frequently asked questions
What does a Zendesk required field actually enforce?
Depends where. A Zendesk required field can be required for the customer to submit, required for the agent to solve, or both, and those are three genuinely different behaviours.
How many custom field types does Zendesk have?
Around a dozen, including drop-down, multi-select, text, multi-line, checkbox, numeric, decimal, date, regex, credit card and lookup relationship. Availability varies by plan, so check yours.
What is the difference between required to submit and required to solve?
Required for end users blocks form submission. Required for agents blocks solving. The second gives you clean data without adding friction for customers.
Can the same custom field appear on several ticket forms?
Yes, and it should. One field, many forms, one id, one report. Duplicating a field per form splits your data permanently.
How do I find a Zendesk custom field ID?
Call the ticket_fields endpoint and read the id, type and title for every field. Resolve ids at startup or keep a per-environment config file rather than hardcoding numbers.
Should I delete unused custom fields?
Deactivate them. Deleting removes the stored values from every historic ticket, which quietly rewrites your reporting history.
Structure helps, it does not dedupe
Good fields make tickets comparable. Ticket Merger uses that structure to spot the same request arriving more than once.
Start free trial14-day free trial. No credit card required.