Adding custom fields to your tickets and support request form

You can add custom fields to tickets, and they can be visible to agents only or to both agents and end-users. You can include custom fields to your support request form by adding them as editable and visible.

After you create your custom ticket field, you can use it in triggers, automations, macros, and views. And if you're on Professional or Enterprise, you can report on custom ticket fields in Explore and Insights.

Tip: If you want to learn more about how to add custom ticket fields to gather information, check out the Zendesk Support for Admins, I training course.

How custom ticket fields work

Custom ticket fields are typically used to gather more information about the support issue or product or service. You can add custom fields to your tickets for agents and you can also add them to your Help Center Submit a Request form if you want end-users to see the custom field. Custom ticket fields can be required or optional.

Note: Zendesk supports up to 2,000 values in custom drop-down and multi-select fields. You can include more values, but performance issues may arise.

Adding a custom ticket field for agents and end-users

You can add custom fields to tickets, and decide if they should be visible to agents only or to both agents and end-users. You can permit end-users to view the custom field in their Zendesk Support ticket by making the field visible, or you can add the custom field to the Request form by making the field both visible and editable.

Note: You cannot alter a field type after the custom ticket field is created. You will need to create a new custom field and remove the original from your ticket form.

Click New Field at the top of the page, and enter a title for the field.

Click the type of custom field you want to create. Hover over the info icon () to view information about each type, including their availability in Insights.

During custom field creation, you can change the selected field type, and any relevant information entered in the steps below will be carried over; however, you cannot change the field type after the new field has been saved.

Enter an optional admin description for the field. This field is only visible to administrators.

Configure the field permissions:

Agent only: Only signed-in agents can view or edit the field.

Editable for end-users: Agents and end-users can view or edit the field.

Read-only for end-users: Signed-in agents can view or edit the field; end-users can view the field.

Enter the field title(s) shown to agents and end-users. Note: The fields displayed and editable here are determined by the field permission setting chosen in the previous step.

Select the field requirements:

Click Required to solve a ticket if the field must be filled out by an agent before changing a ticket status to Solved.

Click Required to submit a request if the field must be filled out by an end-user before they can submit a ticket.

Note: When agents merge a ticket, they do not need to fill in required fields. These are required only when solving a ticket. Merged tickets bypass the Solved status to go directly to Closed. This setting will also be bypassed if a business rule fires in the ticket and changes the status to Solved. This is because a system process is solving the ticket rather than an agent.

If needed, enter a field description to display for end-users.

Depending on the type of field you're creating, you may have the following settings to configure:

Field values (drop-down and multi-select fields): In the Value field, enter a single option you want to include in the list. Hit Enter to submit the value, and display another Value field. Repeat as needed.

Select Show tags to view and edit the tags generated by selecting each option.

Click Order alphabetically to display the options in alphabetical order. Click Undo alphabetical order to return to the original ordering.

Reorder the field values using the drag-and-drop handle () .

Delete a field value by clicking the X to the right of the value.

To choose and display a default value, hover over the selected value and click Make default. Change the default value by selecting another value from the list, or hover and click Undo default.

Note: When you configure a default option in a drop-down list, this applies to new tickets only. If you change an existing ticket form to one that contains a drop-down list with a default option, the default option is not displayed and is shown as blank.

Field option (checkbox fields - optional): If needed, enter an existing tag, or create a new one, to apply to a ticket when the ticket field checkbox is selected.

Field validation (regex): Enter a Ruby regular expression to create an input mask to validate entry.

If you have a large number of values to add for drop-down or multi-select fields, you can bulk import field values.

To check how your custom field will appear to both agents and end-users, click the Preview button. You can enter or select options to see how the field functions. Click Close to return to the custom field screen.

When you’re satisfied with the field, click Save; or, if you want to create another custom field, click the drop-down icon and select Save and add another.

If your custom ticket field does not appear on a new ticket, you might need to restart your browser to see it.

If a ticket field that you previously configured as required is not displayed on the ticket form, it does not need to be entered.

Understanding the persistence of custom field data

If you delete a custom field, the data from the custom field is not preserved in existing tickets, including closed tickets. The data is preserved only if the custom field also adds a tag to a ticket. The three custom fields that add tags are the drop-down list, the checkbox, and multi-select fields. If you delete one of these custom fields, then the data in tickets persist as tags.

For example, suppose you have a drop-down list in your ticket form to associate tickets with different product names. After a while, a decision is made to stop providing support for one of the products. If you remove the product from the drop-down list, the product name persists in existing tickets as a tag. If however you use a text field to record a product ID and you delete the text field, the product ID is not preserved in your tickets.

If you're on Enterprise, your custom ticket fields won't show up until you've added them to whichever ticket forms it should be a part of it. Just go to Gear icon > Manage > Ticket Forms. Click on each form, and drag the custom field over to it.

If you're on the Plus plan or lower, you probably just need to refresh your browser. Sometimes browser caching prevents these types of changes from showing up immediately.

Did something just change with the Name ticket field? Instead of filling in the customer name, it's showing the {{ticket.ticket_field_21694146}} text. I've double checked the field id to ensure that hasn't changed and it looks fine there.

Quick point of clarification: is this a default system field, or a custom field that you created? Can you also point to what business rules you're using that placeholder in? I'd like to take a closer look.

You'll want to go into your custom fields and make sure that the assigned tags line up with what you put in the field itself. If you went through and changed the contents of the fields at any point (for instance, to change the order they appear in the dropdown), I don't think it automatically updates the tag.

Thanks Jessie but I my problem isn't with the tags. If a user selects, "blue" the ticket is tagged with blue. However if you look at the 2nd picture, the color drop down is not selected. It's value is "-". Shouldn't that be blue? If not, why is it there?

It's awfully difficult to say exactly what's happening there with just a couple screenshots...what I'm understanding from your explanation is that your end-user is selecting a color from the drop-down field and the ticket is being tagged correctly, but on the agent end of things the field is showing the tag but no selection in the drop-down. Is that correct?

Is that happening on all tickets, or just a few of them, or just on the one you're using as an example? If you don't mind, I'd like to hop into your Zendesk to take a look at some things and see if I can duplicate the issue. Can you provide me with a couple ticket numbers where this issue has occurred?

Can you change the requirement for the custom field to be mandatory on 'save' or update instead of 'solve' for an Agent..trying to drive the Agents to continue to populate prior to closing, as it impacts reporting of open tickets when they only add information on the backend close of a ticket.

Apologies if this has been asked (and answered) before. I want to set up a custom ticket field for agents that has to be filled in upon solving. This field will basically be a root cause as to why the ticket was raised. As such, I'd like to make different drop down options according to ticket type. Is it possible to link the field to the ticket type?

I have MANY custom fields, and I was able to capitalize the first letters in all of them. Now, when I try to add a new custom field "Equipment Type", when I save it, it appears as "equipment type". I've cleared my cache and even switch browsers. No difference.

What gives? This doesn't look professional on the end user submit ticket page.

Longshot here - but I'm wondering if custom fields can be sent via SMTP headers when a ticket is opened by email?

Here's the use case - we send out alert notifications from our system to our end users, and would like to follow up on them from Zendesk. So we're thinking of CC-ing our support address on the email, which would open a ticket automatically (with the original recipient alerted on changed to that ticket). However - we'd like to pass some custom fields here which would not be present in the email itself (ie - account id).

Interesting question here! The supported method for automating the ticket creation and update process is the API. There is the possibility to update tickets using the Mail API, though this is still designed to be used by an individual Agent and not exactly a means of automation as it only works on forwarded emails originating from agents. Sadly, at this time, it is not possible to manipulate incoming emails and their headers to set custom fields.

There are other options however. For example, you could do a bulk user import that sets custom fields, like account id. You could also create the proactive alters directly from Zendesk Support or using the API and set these values upon creation passed in your payload made in the API request. In this case, Zendesk would do the "heavy lifting" for creating and managing the proactive alters as opposed to your email client. See our Create Many Tickets API resources; we also have a Proactive Tickets App that could be used depending on your plan.