What Is the Difference Between Ticket Fields and Forms in Zendesk? (2026)

A Zendesk ticket field captures one piece of data on a ticket, such as priority or an order number; a ticket form is a named set of fields shown for one type of request. Fields are the building blocks and forms arrange them. Custom fields come with every plan, but multiple forms and conditional fields need Suite Growth or higher (Zendesk's help center, checked September 2026).

If you're newer to the platform, skim how a Zendesk ticket works first. Fields and forms are how you shape that ticket object.

What is the difference between a ticket field and a ticket form?

Think of a ticket as a record in a database. Every column in that record is a field: subject, status, priority, "what product is this about," "what's your order number." A form is a saved layout that decides which of those fields appear, in what order, and with what instructions, for one kind of request.

A useful mental model: you design fields once, then mix and match them into forms for each request type. Change a field's options and it updates everywhere that field is used.

What system fields does every Zendesk ticket have?

Every Zendesk ticket ships with built-in system fields you can't delete (though you can often hide or reorder them). They are the backbone of routing, reporting and automation:

• Subject and Description: the headline and body of the request.
• Status: the ticket's lifecycle stage: New, Open, Pending, On-hold, Solved, Closed.
• Type: Question, Incident, Problem, or Task (a problem can link many incidents).
• Priority: Low, Normal, High, Urgent; this is what most SLA policies key off.
• Requester: the customer the ticket is on behalf of.
• Assignee and Group: the agent and team responsible.
• Tags: free-form labels used heavily by triggers, automations and views.

Type and Priority drive so much downstream automation that we cover them in depth in Zendesk ticket priority and type explained. System fields give you a working ticket out of the box, but they're generic. The moment you need to capture something specific to your business, such as an order ID, a plan tier or a device model, you reach for custom fields.

Which custom ticket field types does Zendesk offer?

A custom ticket field is any field you create yourself. Custom fields are available on every Support and Suite plan (Team, Professional and Enterprise), so having them isn't gated behind an upgrade. The gating, as we'll see, is on forms, conditional logic and one relationship field type.

When you create one, the most important decision is the field type, because it decides how data is entered, validated and, critically, whether it can drive automation. Zendesk lists twelve custom field types you can use on tickets (checked September 2026 against Zendesk's "About custom fields and custom field types" doc). The newest is multi-lookup, which Zendesk limits to Suite Professional and above and Support Enterprise.

The "generates tags" column is the one most people overlook. Per Zendesk's doc, drop-down, multi-select and checkbox fields generate tags, and those tags are what your triggers, automations, macros, views and reports can act on. 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 shows to users, the tag drives business rules); for a checkbox, you enter a single tag that's applied whenever the box is checked. The lookup relationship fields, by contrast, do not generate tags. They store a link to a related record (and aren't available in search or Explore), so they relate records rather than drive tag-based automation. A free-text "Category" field looks tidy but is nearly useless for routing; a drop-down "Category" field can fire a trigger that assigns the ticket to the right group. Rule of thumb: if a value needs to drive automation or reporting, make it a drop-down, multi-select or checkbox, not text.

Required vs. optional, and who can see the field

Two per-field settings shape the experience as much as the type does:

• Required vs. optional. You can require a field before a ticket is submitted, solved, or both. One constraint matters: the required property is set at the field level and applies to every form the field appears on. If you need "Order number" required on the Returns form but optional elsewhere, Zendesk's own guidance is to use separate fields. There's no per-form override.
• 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. Internal triage fields like "Refund approved by" should stay agent-only; "Order number" should be end-user visible so customers supply it up front.

Conditional fields

Conditional fields show or hide a field based on what's selected in another field on the same form. Pick "Hardware" as the issue category and a "Device model" drop-down appears; pick "Billing" and it stays hidden. This keeps a single form short and relevant instead of showing everyone every possible question.

Conditional ticket fields are a paid-tier feature. Zendesk's conditional ticket fields documentation lists Suite Growth, Professional, Enterprise and Enterprise Plus, plus Support Enterprise. Some older third-party guides say Professional and up; the official doc shows Growth and up.

What is a ticket form, and when do you need more than one?

A ticket form is a named, ordered set of ticket fields presented for a specific request type. Every Zendesk account has one built-in Default Ticket Form, and on lower tiers that's all you get. The value comes from creating multiple forms (Zendesk allows up to 300 per account) so each request type asks only its relevant questions.

Why you'd want more than one form

• Different request types. A "Report a bug" request needs steps-to-reproduce and a severity field; a "Request a refund" request needs an order number and amount. Forcing both through one form means every customer sees fields that don't apply to them.
• Different products or brands. Multi-product companies route a "Mobile app" form differently from a "Billing" form, and can match forms to brands.
• Cleaner end-user choice. When end users open your help center, they pick the form that matches their problem from a drop-down, and only that form's fields render. That is far less intimidating than one mega-form.

Form settings that matter

• End-user instructions. Each form has a title and an optional instructions blurb shown to customers. Use it to set expectations ("Include your order number to speed things up").
• Field ordering. You drag fields into the order they should appear; put the highest-signal questions first.
• End-user visible vs. agent-only forms. A form can be available to customers in the help center, or restricted to agents for internal-only request types.

When the default form isn't enough

If you're routing on ticket type tags, asking customers to describe things you could capture in a drop-down, or maintaining a single sprawling form with conditional fields papering over five different request types, you've outgrown the default form and want multiple forms.

Which Zendesk plans include multiple forms and conditional fields?

This is where buyers get tripped up. Here's the breakdown from Zendesk's Creating multiple ticket forms doc and the conditional fields doc, checked September 2026:

The practical takeaway: Suite Team gives you custom fields but only one form and no conditional logic. If your support spans genuinely different request types, Suite Growth is the floor, because it's the tier that unlocks both multiple forms and conditional fields. For where these land in the broader lineup, our Zendesk pricing breakdown walks every tier.

Which field and form mistakes should you avoid?

Do:

• Use drop-downs and checkboxes for anything you'll route or report on. Only those types (and multi-select) generate tags; free text is invisible to automation.
• Keep end-user forms short. Every required field is friction. Ask only what you need to start work, and capture the rest with conditional fields or agent follow-up.
• Name fields for humans. "Order number," not "cf_ord_id_2."
• Standardize before you scale. Agree on a category taxonomy once; retrofitting tags across thousands of tickets is painful.
• Add new fields to every form that needs them. Once you run two or more ticket forms, creating a field does not automatically place it on your forms (not even the default one). You have to open each form and add the field, or it will silently go uncollected.

Avoid:

• The mega-form. Twenty fields on one form tanks completion rates and trains customers to skip the help center entirely.
• Free text where a drop-down belongs. "Region" as text gives you "US", "u.s.", "United States" and "usa": four values for one thing, and no reliable reporting.
• Duplicate forms that drift. Three near-identical forms become three maintenance burdens; consolidate with conditional fields where you can.
• Required-everywhere fields. Because required is set at the field level, marking a niche field required can block submission on unrelated forms. Check where a field is used before flipping that switch.

Can AI fill in ticket fields automatically?

Yes. Well-structured fields are the foundation for automation, but the data still has to get into them, and that's usually manual work: an agent reads the ticket, picks a category, sets priority and tags the product. It's tedious and inconsistent.

An AI agent layer fills that gap. 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 fill in 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 and report more reliable.

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 ticket (one conversation, charged once however many steps it takes, and never per ticket "resolved"), from $299 a month for up to 750 tickets. It adds to your Zendesk setup; it doesn't replace thinking through your fields. If filling in and triaging ticket data is the bottleneck, you can try it on a free trial ($50 of usage, no credit card required).

Frequently asked questions

What's the difference between a ticket field and a ticket form in Zendesk? A field captures one piece of data on a ticket (e.g. priority, order number). A form is a curated set of fields shown together for a specific request type (e.g. a "Returns" form). You build fields once and arrange them into forms.

What ticket field types does Zendesk support? Twelve custom types for tickets: drop-down, multi-select, checkbox, text, multi-line, numeric (integer), decimal, date, regex, credit card, lookup relationship and multi-lookup. Only drop-down, multi-select and checkbox generate tags for use in triggers, automations and reports; the lookup types do not.

Do I need a paid plan for custom ticket fields? No. Custom fields are available on every Support and Suite plan. What's gated is multiple ticket forms and conditional fields, both of which require Suite Growth or higher (Team plans get a single default form only).

How many ticket forms can a Zendesk account have? Up to 300, on Suite Growth and above. Suite Team accounts have only the Default Ticket Form.

Can a field be required on one form but optional on another? No. Zendesk sets the required property at the field level, so it applies to every form the field appears on. To have different requirements, create separate fields.

What are conditional ticket fields? Fields that appear or hide based on another field's value on the same form, e.g. showing "Device model" only when "Issue type" is "Hardware." They require Suite Growth or higher (or Support Enterprise) and keep a single form short and relevant.

When should I create multiple ticket forms? When you support genuinely different request types (bugs vs. refunds vs. account changes), multiple products or brands, or want end users to pick a shorter, relevant form instead of one long catch-all.

What should you fix first?

Fields define what you capture; forms decide which fields a given request shows. The fastest wins for most teams: convert free-text fields that should be drop-downs, trim required fields on end-user forms, and split one overloaded form into a few purpose-built ones (Suite Growth and up). Then your triggers, SLAs and reports all get more reliable, and automating how those fields get filled is where the next time savings come from.

Checked against Zendesk's official help documentation, September 2026. Field types, tag behavior and plan gating change periodically, so confirm the specifics against your own plan before you build.