The Zendesk Ticket Form

Q: Can I link directly to a specific Zendesk ticket form?

Yes. Append `?ticket_form_id=` and the form ID to your help centre new request URL. It's the single best thing you can do with forms.

Q: Do ticket forms work with the API?

Yes, tickets carry a `ticket_form_id`. If you create tickets programmatically and omit it, you get the default form, so set it explicitly when it matters.

One form is the default and it's usually right. The moment you add a second, you have made a routing decision, whether you meant to or not.

Start free trial All guides

What a form actually is

A ticket form is a named set of ticket fields in a chosen order. That is the whole concept. The fields exist independently, as covered in the ticket fields guide, and a form just decides which of them appear and in what sequence.

Which means a form is not a container. Two forms sharing a field share the data in it. Change the field and both forms change. People expect forms to be separate worlds and they are not.

Multiple forms sit above the entry-level plans. Check the current Zendesk docs for which tier your account needs, because this one moves.

When a second Zendesk ticket form beats another field

The honest test is whether the two request types share almost nothing.

Good reason. A returns request needs an order number, a photo and a reason. A technical fault needs a device, a version and steps to reproduce. Nothing overlaps, so one form asking all six questions is a form that asks everyone four irrelevant ones.

Bad reason. You want to know which team handles it. That's routing, and a drop-down plus a trigger does it without making the customer choose a form title they do not understand.

Also bad. One department asked for their own form because they wanted ownership. You now maintain two forms forever for a reason that is organisational rather than functional.

Before adding a form, try conditional fields. One form that reveals the right three questions after the customer picks a category beats two forms they have to choose between blind.

Forms per brand

If you run multiple brands, each form can be restricted to specific brands. This is the setup where forms genuinely shine, because the brands often are separate businesses with separate questions.

Get it wrong and the failure is visible to customers: a form built for your enterprise product showing up on the consumer help centre, asking for a contract number nobody has.

One thing worth checking after any brand change. A form assigned to no brand, or to a brand whose help centre is deactivated, can quietly vanish from the place customers submit from while still looking fine in the admin list.

Linking straight to a form

Every form has an ID, and you can send someone directly to it rather than making them pick from a list:

https://yourcompany.zendesk.com/hc/en-us/requests/new?ticket_form_id=360000123456

This is the most underused thing in Guide. Put the returns form link in the returns article. Put the billing form link in the billing article. Pre-selecting the form means the customer never sees a drop-down of internal-sounding names, and your tickets arrive pre-categorised.

You can go further and prefill fields through URL parameters in many setups. Support for that varies by field type and by theme, so test it on your own help centre before you paste the link into a hundred articles.

What forms do to routing and reporting

A trigger can fire on the ticket form, so the form is a legitimate routing signal. Form equals Returns, assign to the returns group, set priority normal. Clean, readable, no tag gymnastics.

Reporting is where it gets subtle. Explore can slice by form, which is useful, but only for the period since the form existed. Rename a form and old tickets follow the new name. Deactivate one and its tickets keep pointing at it. Neither is wrong, and both surprise people who expected a fixed historical label.

For the strategic question of whether a second form is the right call at all, the ticket forms guide goes into the trade-offs in more depth.

FAQ

Frequently asked questions

Can you link straight to one form, or scope forms per brand?

Both. A Zendesk ticket form URL with the form ID takes a customer straight to it, and Zendesk multiple ticket forms can be scoped so each brand shows its own. A Zendesk form per brand keeps the help centre coherent.

How many ticket forms should we have?

As few as the work allows. Two or three covers most teams. Past about five, customers start guessing, and a guessed form is worse than no form because it looks like real data.

Can I link directly to a specific Zendesk ticket form?

Yes. Append ?ticket_form_id= and the form ID to your help centre new request URL. It's the single best thing you can do with forms.

Can agents change the form on an existing ticket?

Yes, from the ticket itself. Fields on the old form that are not on the new one keep their values, they just stop being visible, which occasionally confuses people looking for data they know was entered.

Do ticket forms work with the API?

Yes, tickets carry a ticket_form_id. If you create tickets programmatically and omit it, you get the default form, so set it explicitly when it matters.

Are multiple ticket forms available on every plan?

No, they need a higher tier. The exact threshold changes, so check the current Zendesk docs against your account rather than trusting a blog post, including this one.