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.
You must be an administrator to create custom ticket fields.
Topics covered in this article:
- How custom ticket fields work
- Adding a custom ticket field for agents and end-users
- Understanding the persistence of custom field data
Related articles:
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.
- Drop-down
- Multi-select
- Text
- Multi-line
- Numeric
- Decimal
- Checkbox
- Date
- Regex
The drop-down list, multi-select, and checkbox custom fields generate tags that can also be used in automations, macros, triggers, reports, and views (see Understanding custom ticket fields, tags, and business rules). All custom fields can be referenced as placeholders (see Placeholders for custom fields).
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.
You must be an administrator to create custom ticket fields.
- Click the Admin icon (
) in the sidebar, then select Manage > Ticket Fields.
- Click the Add field button.
- 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.
For information about the fields types, see About custom field types.
- 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.
- 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.
- 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.
After you create your custom ticket field, you can use it in triggers, automations, macros, and views (see Using custom ticket fields in business rules). However, text or numeric custom ticket fields can only be used in views. If you're using Support Professional or Enterprise, you can report on custom ticket fields in Insights and Explore (see Reporting on custom fields in Insights and Reporting with custom fields).
For more information about creating ticket forms, see Creating ticket forms to support multiple request types (Professional add-on and Enterprise).
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.
135 Comments
Hi,
I would like to add an additional email field that will add addresses to the ticket's CC field. Is this possible?
Thanks.
Hi Uri!
As long as you're on the Team plan or higher, you can set up a Trigger to do this for you. Just a couple things to bear in mind: it'll only work if the people you want to CC are agents, and you'll have to use a drop-down or check box field as the custom field. It's not possible to fire triggers on free text fields.
Hi, I'd like to add a hidden text box to the form, but have is auto populated from an URL value, is this possible?
Hi there!

On our Team plan and above, you have full access to the code of your Help Center. As a result, you should be able to implement Javascript to accomplish this. In general, you'd likely want to add a custom text field to your Request form and then hide it using Javascript. You can then add some JS logic to fill in this text field with the URL parameters. Being custom code, I am not aware of any resources we have on how to go about this but I did find the following resource that seems to discuss what you're looking to do for the URL parameters.
You should be able to hide the field with one line of jQuery that grabs the custom field ID number from the DOM:
$('.request_custom_fields_32175007').hide();
how to add custom drop down ticket field through api?
curl https://{subdomain}/api/v2/ticket_fields.json \
-H "Content-Type: application/json" -X POST \
-d '{"ticket_field": {"type": "tagger", "title": "myfield"}' \
-v -u {emailid}:{password}
{"error":"RecordInvalid","description":"Record validation errors","details":{"field_options":[{"description":"Field options: must contain at least one option","error":"EmptyValue"}]}}
then i created custom drop down from ui. checked its detail and found that option get populated in key named custom_field_options
so i used
curl https://{subdomain}/api/v2/ticket_fields.json \
-H "Content-Type: application/json" -X POST \
-d '{"ticket_field": {"type": "tagger", "title": "myfield","custom_field_options ":"{{\"name \":\"testing \", \"value \":\"testing \"},{\"name \":\"testing1 \", \"value \":\"testing1 \"}}"}}' \
-v -u {emailid}:{password}
but still getting same error.
Gourav -- the contents of custom_field_options should be an array of objects -- so the outer brackets should be square, not curly.
changed custom_field_options to
"custom_field_options ":"[{\"name \":\"testing \", \"value \":\"testing \"},{\"name \":\"testing1 \", \"value \":\"testing1 \"}]"
still getting same error
{"error":"RecordInvalid","description":"Record validation errors","details":{"field_options":[{"description":"Field options: must contain at least one option","error":"EmptyValue"}]}}
tried
"custom_field_options ":[{\"name \":\"testing \", \"value \":\"testing \"},{\"name \":\"testing1 \", \"value \":\"testing1 \"}]
but got error
{"error":"Unprocessable Entity","message":"Server could not parse JSON"}
Since the JSON text is enclosed in single quotes, you should not need to escape any double quotes. Just quote the items normally.
@jacob i already tried that
curl https://{subdomain}/api/v2/ticket_fields.json \
-H "Content-Type: application/json" -X POST \
-d '{"ticket_field": {"type": "tagger", "title": "myfield","custom_field_options ":[{"name ":"testing ", "value ":"testing "},{"name ":"testing1 ", "value ":"testing1 "}]"}}' \
-v -u {emailid}:{password}
Response:-
{"error":"RecordInvalid","description":"Record validation errors","details":{"title":[{"description":"Title: cannot be blank","error":"BlankValue"}]}}
Gourav, you've got the right approach with this last one but it seems clear that you have typos or other syntax errors. This latest example has an extra quote after the square brace, and some extra spaces within the quotes. That last example looks correct otherwise, though -- keep trying to fix that one.
Thanks for helping out, Jacob!
Hi there,
Is there a way to make a custom field not changeable for agents(maybe greyed out)?
So they only can see what the customer choose?
Because I only want customers to edit this field.
Thanks.
Hi Ramon!
It's not possible to restrict a field so an agent can't edit it, I'm afraid. It's only possible restrict end-users from editing them.
Can you tell me more about your use case?
Hi Jessie,
Our customers that use our webform enter an ticket-question-type (it's required).
That way we route tickets to the right group.
But an agent that views this ticket can change the ticket-question-type, but if they change this the right path is not followed (also my reports are not messed up). So thats why I would like to lock this field.
Thanks.
Ramon
Have you tried not showing the field on the left hand side in your forms in Zendesk, to not allow the field to be visible or do you need the agents to still see it?
I don't know what you mean, Where can I find this?
The field must be visible for customers, but greyed out or not visible for agents.
https://support.zendesk.com/hc/en-us/articles/203661636-Managing-your-ticket-forms-Professional-Add-on-and-Enterprise-
Thanks for jumping in, Amy!
@Ramon, the only solution I can think of here is to set up some triggers to automatically change the field back if it's been altered by an agent.
When a selection is made in a drop-down menu, a corresponding tag is added to the ticket. You could set up a series of triggers to test whether the original tag exists, and whether it matches the current menu selection, and if it doesn't it'll change the menu selection back to what it should be.
It'll be pretty labor intensive to set up, especially if the drop-down in question has a lot of options in it, but once it's done it should take care of the issue.
Thanks for your help!
But I think it's a bit to much work.
Regarding the persistence of data, there are times we want to deactivate certain options, but retain that data in a format other than tagging. In the past, when making a significant change, we created new fields and deactivated the previous ones (which our reporting analyst loved); however for one or two options changes, this is not a reasonable approach. Are there any plans to have the ability to deactivate options in a field rather than either delete them and rely on tags, or create an entirely new field?
Hi David! Thanks for sharing your feedback on this! I can't speak to whether this is something we're looking at right now, but I didn't find a new-ish thread about this in our Product Feedback forum. You can find that here: Deactivating custom fields.
There are only a couple comments right now, but I'd still encourage you to add your vote and detailed use case. This will help our Product Managers understand what you're trying to accomplish so they can figure out the best way to help you do it. (Bear in mind, they're not always able to respond).
Is it possible to enable a wysiwyg UI for description when using the {{request_form}} helper?
Hey Graham -
It is not possible to add the WYSIWYG YI to the Help Center submit a request description text field. We do offer a WYSIWYG helper, but it's for editing article and most comments.
Hi! Is it possible to show the user an answer to his question right after he chooses the category to which this question is related?
For example, we have only Visa and MasterCard payment options available on our website. And it would be great to show the user this information right after he chooses from drop-down list "Payment options" category of question.
If this option is not available, please suggest the closest solution to my needs. The main goal is to answer some of the questions immediately to save time of our support team.
Hey Frank!
If you're on the Professional or Enterprise plan, the Conditional Fields app may do what you're looking for.
Otherwise, when you're creating a custom field, you can set a description for fields that are editable by your end users. You could include accepted payment methods there.
Also, when your users start typing a subject for their support request, Guide will automatically suggest articles that may answer their question. If you have an article in your knowledge base that has this information, it should show up in the suggestions as long as the user is using the right keywords.
If a user still ends up submitting a ticket after all of these deflection efforts and you're using Guide Professional, you could use Answer Bot to automatically suggest your articles pertaining to the payment methods you accept.
If you're not interested in using Answer Bot, and you're on at least the Team plan, you could set up a trigger to send an email to any customer who selects that option from your drop down menu.
Hopefully one of those options will work for you!
Jessie, thank you very for your detailed answer! I'll discuss it with our QA, hope that some of the solutions will be applied to our website.
How can i remove the source of information from the submitted ticket information.
Hello there. I tried to add custom fields of different types at Admin/Ticket fields but when I try to create request and provide this fields as objects in the `custom_fields` array they are not added to the tickets. For { id: someId, value: 'someValue' } I see either nothing in response (if field is invisible) or { id: someId, value: null } if field is set as visible and field itself isn't added to the ticket. Should it be enabled somewhere else?
Hi Account team,
I'm going to create a ticket so we can discuss this one in a bit more depth from there. See you in the ticket. :)
Hi Roman,
It seems that you have a ticket open with us already. It is a ticket open by Kent and you are CC'd on it. Since these are account related questions, for security purposes you will get answers within this ticket.
If you have any other question, you can log into help center and look at your activities to see which ticket you are CC'd on.
Cheers,
Please sign in to leave a comment.