Zendesk Custom Fields Explained (Types, Users & Organizations)
Out of the box, a Zendesk ticket knows a handful of things: who asked, what the subject is, its status, priority, and type. That's enough to run a help desk — but it's not enough to run your help desk. Your tickets probably need to capture an order number, a plan tier, a product line, a region, or whether the customer is a VIP. None of that exists by default. Custom fields are how you teach Zendesk to record the data your business actually cares about.
This guide is the focused deep dive on custom fields specifically: the eleven custom ticket field types and what each is for, which types quietly generate tags (and why that matters), the per-field settings that control who sees a field and whether it's required, and — the part most guides skip entirely — that custom fields don't only live on tickets. They also live on users and organizations. Everything here is verified against Zendesk's current help documentation (June 2026).
If you're still untangling the broader picture of how fields relate to forms, start with our companion piece on ticket fields vs. forms — this post assumes you know a field is one data point and goes deep on the custom kind.
What a custom field is — and why it matters
A custom field is any field you create yourself to capture data Zendesk doesn't collect by default. Zendesk ships with system fields — Subject, Description, Status, Type, Priority, Group, Assignee, Requester, Tags — that you can't delete. Custom fields are the ones you add on top, and they're where Zendesk stops being a generic inbox and starts being shaped to your operation.
The payoff isn't just tidier records. Structured custom-field data is what lets Zendesk route ("Product line" → the right team), prioritize ("Customer tier" → the right SLA), collect context up front (an end-user "Order number" field), and report on anything specific to your business — "How many refund tickets came from Enterprise accounts last quarter?" is only answerable if both facts live in fields. (We unpack each of those mechanisms further down.)
The catch — and the theme of this whole guide — is that the field type you choose determines how useful the data is. Get it right and the field powers automation and reporting. Get it wrong (free text where a list belonged) and you've collected data you can't reliably use.
The eleven custom ticket field types
When you create a custom ticket field (in Admin Center → Objects and rules → Tickets → Fields), the first and most consequential choice is the type. Zendesk supports eleven custom ticket field types, verified against Zendesk's "About custom field types" documentation:
| Field type | Best for | Generates tags? |
|---|---|---|
| Drop-down | One choice from a fixed list (up to 2,000 values) — category, product, reason | Yes |
| Multi-select | Several choices from a list (up to 2,000 values) — affected features | Yes |
| Checkbox | A single yes/no flag — "VIP," "data-loss reported" | Yes |
| Text | A short single-line answer (up to 65,536 chars) — order number | No |
| Multi-line | A longer free-text answer — "steps to reproduce" | No |
| Numeric | Whole numbers only — quantity, seat count | No |
| Decimal | Numbers with decimals — refund amount | No |
| Date | A date picker — event date, requested delivery | No |
| Regex | Text validated against a pattern — SKU, postal code | No |
| Credit card | A card number where only the last four digits are stored/shown | No |
| Lookup relationship | A link to a related user, organization, or custom-object record | No |
A few of these deserve a closer look because they're easy to misuse:
- Drop-down vs. text is the single most important decision you'll make repeatedly. A drop-down constrains input to a known list, so the data stays clean and machine-readable. Free text lets a customer (or agent) type "US," "u.s.," "United States," and "usa" — four spellings of one value, and zero reliable reporting. Reach for text only when the answer is genuinely open-ended prose.
- Lookup relationship is the newest and most misunderstood type. Instead of storing a value, it stores a link to another record — a user, an organization, or a custom object (e.g. tying a ticket to a specific asset or contract). It's powerful for relating records, but note its limits: it doesn't generate tags and isn't available in search or Explore reporting, so it's for connecting data, not slicing it.
- Credit card masks all but the last four digits, so it's the only safe way to capture a card reference in a ticket — never use a plain text field for that.
Which field types generate tags (and why you should care)
This is the detail that separates people who get Zendesk from people who fight it. Three ticket field types automatically generate tags: drop-down, multi-select, and checkbox. Tags are the connective tissue Zendesk uses to act on field values.
The mechanics differ slightly by type:
- For drop-down and multi-select, each option is a title + tag pair you define per value — the title is what users see, the tag is what your automation reads.
- For a checkbox, you enter a single tag that gets applied to the ticket whenever the box is checked.
The other eight types (text, multi-line, numeric, decimal, date, regex, credit card, lookup relationship) store a value but generate no tag. That's the crux of the most common custom-field mistake: a free-text "Category" field looks tidy, but because it produces no tag, your triggers and views can't act on it. A drop-down "Category" with the same options can fire a rule that routes the ticket the instant it arrives. Rule of thumb: if a value needs to drive automation or reporting, make it a drop-down, multi-select, or checkbox — not text.
Required, visibility, and conditional settings
Two per-field settings shape the experience as much as the type does, plus one form-level behavior worth knowing:
- Agent-only vs. end-user-visible. Each field can be visible to agents only, or also shown to (and editable by) end users in the help center and web form. Keep internal triage fields like "Refund approved by" agent-only; make "Order number" end-user visible so customers supply it up front.
- Required vs. optional. You can require a field before a ticket is submitted, solved, or both. Important constraint: the required property is set at the field level and applies to every form the field appears on — there's no per-form override. If you need "Order number" required on a Returns form but optional elsewhere, you'll need separate fields.
- Conditional fields. A conditional field shows or hides based on another field's value on the same form (pick "Hardware" → a "Device model" drop-down appears). This keeps one form short instead of overwhelming everyone. Conditional ticket fields require Suite Growth or higher — they're not available on Team plans (Zendesk: Creating conditional ticket fields).
Custom fields aren't just for tickets: users and organizations
Here's the part many admins never discover: custom fields also exist on user profiles and on organization records, not only on tickets. This is one of the most underused features in Zendesk, and it changes how you think about data.
- Custom user fields attach data to a person — a loyalty number, account type, signup date, "internal champion." You set them under Admin Center → People → Configuration → User fields (Zendesk: Adding custom fields to users).
- Custom organization fields attach data to a company — contract tier, account manager, renewal date, region. You set them under Organization fields (Zendesk: Adding custom fields to organizations).
Why this matters: data on a ticket describes one request; data on a user or organization describes the customer, and it persists across every ticket they ever open. Capture "Plan tier" as an organization field once, and every ticket from that company inherits the context — no re-asking, no re-tagging.
(A note on how we verified this: the ticket Fields admin in the screenshot above is a first-hand capture from our own Zendesk dev instance. The User fields and Organization fields admin screens sit behind a login wall on that test account, so rather than fabricate a screenshot we've described those screens and cited Zendesk's official user-fields and organization-fields docs for every type and behavior claim below.)
User and organization fields support the same types as ticket fields with one exception: credit card is not supported. Zendesk's docs are explicit — the user-fields doc states "Credit card fields are not supported for users," and the organization-fields doc says admins can "create any custom field type for an organization, except credit card." So for users and orgs you get drop-down, multi-select, text, multi-line, numeric, decimal, checkbox, date, regex, and lookup relationship — multi-select is fully supported (both docs reference configuring "drop-down and multi-select fields"); credit card is the only ticket type that's off the table. But two behaviors are different from ticket fields:
- They use a field key, not a tag, by default. Each user/org field has a field key used in placeholders and the API rather than generating a ticket tag automatically.
- **Drop-down and checkbox user/org fields can optionally add tags to tickets. There's a setting that applies the value's tag to that user's (or organization's) tickets — so a "VIP" checkbox on an organization can tag every ticket that company submits. And drop-down/checkbox user and organization fields can be used directly in business-rule conditions** (e.g. "requester's account type is Enterprise"), which is how you route or escalate based on who the customer is, not just what they're asking.
The practical upshot: put customer attributes on the user or organization, and per-request attributes on the ticket. Mixing those up (re-collecting "Plan tier" on every ticket) is a classic source of dirty data.
How custom fields power the rest of Zendesk
Custom fields aren't an end in themselves — they're inputs to everything else. Once the data is structured, your business rules can read it:
- Triggers fire on field values the moment a ticket is created or updated — "if Product = Billing, assign to the Finance group."
- Automations run on a schedule against field values — "if Priority is High and Status is Pending for 24 hours, escalate."
- Views filter and group tickets by any field — a queue of "Open tickets where Region = EMEA."
- SLAs can target tickets by field — a tighter response target for "Customer tier = Enterprise."
- Explore reporting lets you slice metrics by field values — volume by product line, resolution time by category.
Every one of these is only as good as the field feeding it. A free-text field that should have been a drop-down is invisible to all five. This is why the type decision compounds: get it right once and routing, SLAs, and reports all get more reliable for free.
Limits and plan availability
A few constraints worth keeping in mind:
- Value limits. Drop-down and multi-select fields support up to 2,000 values each; text and multi-line fields hold up to 65,536 characters.
- Plan gating. Custom ticket, user, and organization fields are available on all Support and Suite plans (Team and up) — there's no upgrade required just to have custom fields. What's gated is conditional ticket fields (Suite Growth+) and multiple ticket forms (Suite Growth+); the fields themselves aren't.
- Forms don't auto-update. Once you're running two or more ticket forms, creating a new field does not automatically add it to your forms — you must open each form and add it manually, or the field silently goes uncollected.
Best practices and common mistakes
Do:
- Use drop-downs/checkboxes for anything you'll route or report on. Only those types (plus multi-select) generate tags — free text is invisible to automation.
- Put customer attributes on users/orgs, request attributes on tickets. Don't re-collect "Plan tier" on every ticket when it belongs on the organization.
- Name fields for humans ("Order number," not "cf_ord_2"), and define a small, agreed taxonomy before you scale.
- Mask sensitive data with the credit card type — never plain text.
Avoid:
- Free text where a drop-down belongs — the "US / u.s. / usa" problem destroys reporting.
- Too many fields. Every required field is friction; a 20-field intake form tanks completion rates. Capture only what you need to start work and use conditional fields for the rest.
- Required-everywhere fields. Because required is set at the field level, marking a niche field required can block submission on unrelated forms.
- Ignoring user/org fields and cramming customer-level data onto every ticket.
Where AI fits: stop hand-filling fields
Well-structured fields are the foundation for automation — but the data still has to get into them, and that's usually an agent reading a ticket, picking the right category, and setting priority by hand. It's tedious and inconsistent, which quietly undermines the clean data your rules depend on.
This is the gap an AI agent layer fills. Macha runs on top of Zendesk (it's not a help desk and not a Zendesk replacement) and can read an incoming ticket, classify it, and auto-populate the custom fields and tags — set the type, choose the right drop-down category, flag urgency — before a human opens it. Cleaner field data then makes every downstream trigger, SLA, and report more reliable, which compounds nicely.
The honest caveats: it's another integration to manage, classification is only as good as the categories and examples you give it, and Macha is priced per AI action (it bills for the automation work it does — summarizing, tagging, routing, drafting — not per ticket "resolved"). It's additive to a well-designed field setup, not a substitute for one. If auto-filling and triaging field data is your bottleneck, you can try it on a 7-day free trial, no credit card required.
Frequently asked questions
What is a custom field in Zendesk? A custom field is one you create yourself to capture data Zendesk doesn't collect by default — an order number, plan tier, product line, or VIP flag. Custom fields exist on tickets, on user profiles, and on organization records, and they're what your triggers, SLAs, views, and reports read from.
What are the custom ticket field types in Zendesk? There are eleven: drop-down, multi-select, checkbox, text, multi-line, numeric (integer), decimal, date, regex, credit card, and lookup relationship (which links a ticket to a related user, organization, or custom-object record). Only drop-down, multi-select, and checkbox generate tags for use in business rules — the rest store a value but no tag.
Do custom fields exist on users and organizations too, or only tickets? Both. Beyond ticket fields, Zendesk supports custom user fields (data on a person) and custom organization fields (data on a company). They persist across every ticket that user or org opens, so you capture customer-level attributes once instead of re-tagging every ticket. User and org fields support the same types as ticket fields except credit card — multi-select is supported (Zendesk's docs state "Credit card fields are not supported for users" and that you can "create any custom field type for an organization, except credit card"). Drop-down and checkbox user/org fields can optionally add tags to tickets and be used in business-rule conditions.
Which Zendesk custom field types generate tags? Drop-down, multi-select, and checkbox. For drop-down and multi-select, each option is a title + tag pair you define; for a checkbox, you set one tag applied when it's checked. Text, multi-line, numeric, decimal, date, regex, credit card, and lookup relationship generate no tags — so use a drop-down for anything you'll route or report on.
Can a custom field be required on one form but optional on another? No. The required property is set at the field level and applies to every form the field appears on. To require a field on only one form, create a separate field for that form.
Do I need a paid plan for custom fields? No — custom ticket, user, and organization fields are available on all Support and Suite plans. What requires Suite Growth or higher is conditional ticket fields and multiple ticket forms, not custom fields themselves.
The bottom line
Custom fields are how you turn a generic ticketing tool into one that captures what your business actually runs on — and the two decisions that matter most are type and location. Choose drop-downs, multi-selects, and checkboxes for anything you'll automate or report on (they're the only types that generate tags), and reserve free text for genuine prose. Then remember that fields aren't only for tickets: customer attributes belong on users and organizations, where they persist across every request and can still drive routing and tagging. Get those choices right and your triggers, SLAs, views, and reports all get cleaner and more reliable. From here, see how fields combine into intake layouts in ticket fields vs. forms, and how the tags they generate feed business rules.
Verified against Zendesk's official help documentation, June 2026. Field types, tag behavior, and plan gating change periodically — confirm specifics against your own plan and Zendesk's current docs before you build.
