The Ticket Field Manager Zendesk Gives You

Fields are easy to add and nobody ever removes one. Three years in, the ticket field manager Zendesk gives you shows a list that's unreadable and half empty.

Start free trial All guides

What the ticket field manager Zendesk provides hides

Zendesk keeps the ticket field list in Admin Center, in the objects and rules area. It is a flat list: the system fields you cannot remove, every custom field anyone has ever added, each one marked active or inactive. Page names have shifted over the years, so if your account reads differently, the thing you want is the list of ticket fields rather than the form editor.

The flatness is the problem. Nothing on that page tells you which fields hold data, which forms show them, or who asked for them two reorganisations ago. A hundred fields look exactly like ten, only longer.

So the first job isn't tidying. It's finding out what's actually in use, because every decision after this one depends on that answer.

Audit before you touch anything

You want a fill rate per field: of the tickets created in the last ninety days, how many carry a value. That number sorts the list into keep, question and kill faster than any opinion in a meeting.

Export and count. Pull a ticket export covering a recent quarter, then count non-empty values per column. Anything under a few percent is a candidate for retirement unless it exists for a rare, high-stakes case.

List the fields via the API. The ticket fields endpoint returns type, creation date, position and active state for every field. It won't give you usage, and it does give you a clean inventory to work from.

Find the dependents. Search your triggers, automations, views, macros, SLA policies and Explore reports for each doomed field. This is the step people skip. A field that feeds a trigger condition is load-bearing even when agents never fill it in.

Check the forms. A field on eight forms is a different problem from a field on one. See ticket forms for how that mapping works.

Do the audit in a spreadsheet, not in the admin interface. You want to think about the whole list at once.

Deactivate, almost never delete

Deactivating a field takes it off the forms and out of the way for new tickets while leaving historical values intact, which means your old reports keep working. Deleting removes the field and the data in it. Zendesk warns you about that. The warning is accurate and people click through it anyway.

One quiet advantage of drop-down fields: each option carries a tag, and tags stay on the ticket after the field goes. If your reporting is built on tags rather than field values, retirement costs you nothing historically.

There's one case where deleting is the right call: a field somebody created by mistake last week, on no form, referenced by nothing, holding no values at all. Delete that and move on. Anything older than a quarter deserves the slower route.

Give every retirement a quarantine period. Deactivate, wait a month, see who complains. Nobody complains about a field that was never filled in, and if someone does, you have learned something the export didn't tell you.

Scope, don't multiply

Most bloated field lists grew because someone needed a field for one workflow and adding a new one was easier than negotiating over an existing one. There are two proper answers to that pressure.

Ticket forms. Each request type shows its own subset. A returns form and a technical fault form share a requester and nothing else, so they should not share a field set.

Conditional fields. Show a field only once an earlier answer makes it relevant, which keeps a long form short for the person filling it in. The mechanics are in conditional fields.

A useful test for anything that appears on every form: could every requester answer it? If the answer is no, it belongs on one form, not on all of them.

Rules that stop it growing back

One owner. Somebody signs off on every new field. Not a committee, one person who can say no.

Name the consumer. A request for a new field has to name the report, trigger or view that will read it. "It would be useful to know" is not a consumer.

Prefix by domain. Billing, Shipping, Device. The list sorts itself and duplicates become obvious the moment somebody proposes one.

Kill the duplicates first. Two drop-downs both meaning category, built two years apart by different people, is the most common finding in any audit. Pick one, migrate the tags, retire the other.

Review the newest ten quarterly. New fields go stale fastest, because the project that needed them ends and nobody tells you.

FAQ

Frequently asked questions

How do you deactivate a Zendesk ticket field safely?

Run a Zendesk field audit first: check which forms use it and whether anything reports on it. Then deactivate the ticket field rather than deleting it, because deactivating keeps historic values readable. To manage Zendesk ticket fields at scale, do that quarterly rather than never.

Where is the ticket field manager in Zendesk?

In Admin Center, under the objects and rules section, on the ticket fields page. The navigation labels have changed over the years, so look for the field list rather than a specific menu name.

Should I delete or deactivate an unused ticket field?

Deactivate. It removes the field from forms while keeping historical values and existing reports intact. Deleting destroys the data and cannot be undone.

How do I find out which Zendesk fields are actually used?

Export tickets from a recent quarter and count non-empty values per field. Then search your triggers, views, macros and reports for references, because a field agents ignore can still be driving automation.

How many custom ticket fields is too many?

There is no hard limit worth quoting. The practical ceiling is whatever an agent can scan without missing something, which in most teams is well under a dozen visible on any one form.