Ticket Merger

Zendesk Ticket Fields

Every ticket carries Zendesk ticket fields you didn't create, plus however many your team has added since. Knowing which is which saves a lot of confusion.

Start free trialAll guides

The Zendesk ticket fields you already have

Requester, Assignee, Subject, Description, Status, Type, Priority, Group and Tags ship with every Zendesk account. You can't delete them. You can rename some labels and hide a few from the end user form, but the field itself is permanent, because the rest of the product is built on top of it. Triggers read Status. Views filter on Group. Explore reports on Type. Break one and things break a long way downstream.

Two get misunderstood constantly.

Type. Question, Incident, Problem, Task. Incident and Problem are the pair that link tickets to a known outage. Most teams use Type as a loose category instead and never touch problem linking, which is fine, right up until somebody builds a report on it.
Priority. It does nothing on its own. Priority only matters if an SLA policy or a view sort actually reads it. A queue where everything is Urgent is a queue with no priority at all.

The field types and what each is for

Custom fields come in a fixed set of types. Picking the wrong one is the mistake that costs you later.

Text and multi-line text. Free entry. Fine for a serial number, terrible for anything you want to report on, because nobody spells things the same way twice.
Drop-down. One value from a list. This is the type you want for categories. Each option carries a tag, which is how the value reaches your triggers and your reports.
Multi-select. Several values from a list. Useful, and it makes reporting fiddlier, so use it only when a ticket genuinely can be two things at once.
Checkbox. True or false, and ticking it adds a tag to the ticket. Great for a simple flag like "callback requested".
Numeric, decimal and regex. For order numbers, amounts and anything with a format you can validate. Regex fields are underused and they stop a lot of rubbish at the door.
Date. For a real date, such as when a customer travels or when a licence expires. Not for a timestamp Zendesk already tracks.
Lookup relationship. Points at a user, an organization or a custom object, so the ticket references the actual record rather than a typed-in copy of it.

A masked credit card type also exists on some plans. If you're anywhere near payment data, check the current Zendesk docs and your own compliance rules before you turn it on.

Visibility, and required on solve

Each custom field has permissions attached: agents only, editable by end users, or visible to end users but read only. Get this wrong and customers see your internal escalation reason. It happens more often than anyone admits.

Then there are the two required settings. Required to submit applies to end users filling in the form. Required to solve applies to agents, and it blocks the Solve button until the field has a value.

Required on solve is the setting people fall in love with and then regret. Two traps.

The first is a field that only appears on one ticket form but is required across all of them, so agents hit a wall on tickets where the field isn't even visible. The second is bulk updates. Solving forty tickets at once gets awkward when each one needs a category picked by hand.

Two required fields is a good limit. Three is pushing it. Beyond that, agents start picking whatever is first in the list, and your data quality goes down rather than up.

The ticket fields API

Every field has a numeric ID, and that ID is what you need for almost anything programmatic. List them all with a single call:

curl -u you@example.com/token:APITOKEN \
  https://yourcompany.zendesk.com/api/v2/ticket_fields.json

That returns the type, the title, the tag for each drop-down option and the ID. Setting a value when you create or update a ticket looks like this:

{
  "ticket": {
    "custom_fields": [
      { "id": 360001234567, "value": "billing_refund" }
    ]
  }
}

The gotcha that catches everyone: for a drop-down, value is the option tag, not the label the agent sees. If your option reads "Billing, refund" and its tag is billing_refund, the API wants the tag. Send the label and you get a silent mismatch rather than an error.

More on the wider surface in the Zendesk ticket API guide.

Keeping the list from sprawling

Fields accumulate. Somebody adds one for a campaign in March and it's still on the form in November, empty on nine tickets out of ten.

Audit once a year. Export a few thousand tickets, count how often each custom field has a value, and deactivate anything under about five percent. Deactivating keeps the historical data, which is why it beats deleting.

A form with twenty fields isn't a rich data model. It is a form nobody fills in honestly.
FAQ

Frequently asked questions

Which Zendesk field types should you use?

Drop-downs for anything you report on, text only when you truly can't enumerate the answers. Zendesk custom ticket fields sprawl because text is easy, and the Zendesk field types that make reporting possible are the constrained ones.

What is the difference between a system field and a custom field in Zendesk?

System fields such as Status, Priority and Group come with the account and can't be deleted, because Zendesk itself depends on them. Custom fields are the ones you create. You can deactivate them whenever they stop earning their place.

Can I make a Zendesk field required only on some forms?

Required to solve is a property of the field rather than the form, so it applies wherever the field is active. Conditional fields are the fix. They let you require a field only when another value is selected, which is usually what people actually wanted in the first place.

How do I find a Zendesk ticket field ID?

Call GET /api/v2/ticket_fields.json, or open the field in Admin Center and read the ID from the URL. Both give you the same number.

Should I use a drop-down field or a tag?

Drop-down, nearly always. It gives you a controlled list, it reports cleanly, and each option applies a tag anyway, so you get the tag behaviour for free without the spelling mistakes.

How many custom fields is too many?

There's no hard rule. The practical ceiling is whatever agents will fill in accurately under pressure, and most teams are past it somewhere around a dozen visible fields on one form.

Good fields, cleaner matching

The more structure a ticket carries, the more confidently duplicates can be spotted. Ticket Merger finds them and merges them before two agents reply.

Start free trial

14-day free trial. No credit card required.

Keep reading

Zendesk Custom Fields and Ticket Forms
How to use Zendesk custom fields and ticket forms without making customers fill in a survey, plus the fields that pay for themselves in reporting.
Zendesk Conditional Fields: Show the Right Fields
How Zendesk conditional fields work on ticket forms, setting up agent and end-user rules separately, which field types can drive them, and where they break.
Zendesk Ticket Forms: When to Add a Second One
When a second Zendesk ticket form beats another custom field, how conditional fields keep it short, and what forms do to your routing and your Explore reports.
Zendesk Ticket Comments: Reading and Adding Over the API
How Zendesk ticket comments work over the API: listing a conversation, adding a public reply or an internal note, and the read and write split that trips people up.
Custom Object Zendesk: Schema, Records and API
How a custom object in Zendesk really works: object types, fields, records, the API behind them, and the point at which a custom field stops being enough.