Typically, when end users submit support requests, they provide the subject and description of their question or support issue in system ticket fields. They may also be prompted to provide additional data such as a product type or model number using custom ticket fields.
Collectively, the predefined set of ticket fields are a ticket form. Ticket fields on a ticket form, are visible to end users in the contact form, in the Help Center or Web Widget for example, and to agents in a ticket, as shown here. You can activate
Tickets contain other data that you can access using placeholders and the Zendesk API. See Ticket data.
There are two types of ticket fields:
-
System ticket fields are the standard, default fields that agents see in a ticket. Additional system fields are added to the ticket page when you activate additional Zendesk Support features, such as ticket sharing. You can deactivate and reactivate some (but not all) of the system fields.
See the complete list of system ticket fields below.
-
Custom ticket fields can be created in addition to system ticket fields to gather additional information from the person who is requesting support. For example, you may add a custom field prompting them to select a product name or model number.
See the following articles:
- Optimizing your ticket form to understand ticket fields and do some planning to build an optimal ticket form.
- Adding custom fields to your tickets and support request form to create the custom ticket fields you need.
You can view and manage all of you ticket fields on the Ticket fields admin page. See Viewing your ticket fields.
System ticket fields
The system ticket fields that are part of a ticket by default are detailed below. Some system fields are inborn and cannot be reconfigured. See What are the inborn system ticket rules.
System field | Description |
---|---|
Requester | All tickets require a requester. The requester is the person who made the support request.
If a ticket is created by an agent and the requester field is left empty, then the agent will be the requester of the ticket. If needed, the ticket requester can be changed to someone else. See Updating the ticket requester. You can also create a ticket on someone else's behalf. See Creating a ticket on behalf of the requester. |
Follower | Followers can be agents, light agents, or admins, but not end users. Similar to a persistent BCC, followers receive notifications when ticket updates occur, and they can view and create internal notes. Followers are invisible to end users, but CCs are not. See When to use CCs and followers. |
Assignee | The assignee can be either a group or a specific agent. See Manually assigning a ticket to yourself, another agent, or a group. |
CCs | If you have been configured to allow it, other people can be copied on tickets. Both the requester and agents can add CCs to a ticket. The requester does it by adding CC email addresses if they requested support via your support email address. Agents can add CCs using the CC field when updating the ticket. See Using CCs, followers, and @mentions. |
Share | The Share field is only displayed if you have enabled ticket sharing, which means that tickets can be shared with other Zendesk Support accounts. See Sharing tickets. |
Subject | The Subject field is required. It's typically included in the support request submitted by the requester. For example, when someone submits a support request via email, the subject line of the email is used as the ticket's subject. If the ticket title does not appear in the ticket subject, your Subject field might not be visible to end users. To correct this, see this Support Tech Note. |
Description | The Description field is required. This is the text of the support request. When an end user submits a support request via email, the body of the email request is used as the description. The description becomes the first comment in the ticket. |
Status | There are six values for status. A ticket's status can be set and updated either manually by an agent or automatically via your business rules.
|
Type | There are four values for type. Setting the type helps you to categorize your tickets, which you can then use in your workflow. For example, you can create views of tickets by their type. While the field can be blank initially (and through any number of updates), once you change the field to a specified type, you can't change it to blank again.
If an administrator deactivates the Type field, all your tickets default to Incident. |
Priority | There are four values for priority: Low, Normal, High, and Urgent.
By default, all of these four values are available, but you can allow only the Normal and High values to appear. To do so, edit the priority field, then change the setting under Field values. Priority is not a required field, so you do not always need to select a value. How you weigh the priority of your tickets is up to you. |
Tags | Tags are used throughout to add additional information to tickets, which can then be used in your ticket workflow. Tags can be added to tickets in the following ways:
Tags are enabled by default but can be disabled. See Enabling and disabling ticket tags. |
102 Comments
Yikes! Thanks for sharing that C F :)
I did not realize those were switched around above.
I'll pass this feedback along to the appropriate team to get corrected.
I appreciate you taking the time to share this with us!
Brett and C F, I’ve updated this article so that, hopefully, this clears up the confusion over the definitions for Incident and Problem. Thanks for the feedback!
Hi,
We had disabled the standard "Type" field and create the custom field to replace "Type" field in Zendesk, and the Zendesk is integrated to SFDC, how can I shows the custom field instead of standard Type field in SFDC, as all tickets type shows as "Incident" which is very misleading to our sales rep. thanks.
Hi Nicole,
I've had this challenge in the past as well. I am not a fan of incident being the default option when the Type field is disabled. However, you could enable the field and just remove it from your forms. Then you can use a trigger to set the value that you want on ticket creation behind the scenes so it displays more appropriately in Salesforce.
The field "organisation" pops up when the end user is linked to more than one organisation. Can i rename this field? As the word organisation doesn't mean much to my customers.
Hello Heather Cook,
So via the base client, this would not be able to be edited as you described. You could edit this via the API through custom code, which I've gone ahead and linked an article below that goes into the basics of this. I would also suggest posting this idea in our Support Product Feedback forum so our developers can consider this for potential future updates.
Support API
Best regards.
Is it possible to hide the priority field so it isn't visible to end users in the helpcenter when they view their tickets? We make use of it to internally prioritize, but we don't use "Low" as we don't want the customers to see that.
Hey Steve,
If you navigate to Admin > Manage > Ticket Fields you can edit the Priority field to make it visible to only agents on the account.
Let me know if that doesn't get you the results you're looking for.
Cheers!
Hi all, fairly new to ZenDesk and still learning on the product. On thing I'd like to see in ZenDesk Support is the ability to be able to change the labels in the status of tickets.
For an agent it may make sense to read Open, Pending, etc but for the end user it'd be better if the status would show something like Open = Working on it..., Pending = Waiting for customer...
Seeing Open on a ticket does not give the end user any sense an agent is working on the problem, nor seeing Pending means they have to respond with more information.
Hi Federico Deis -
I assume here you're referencing when the agent is looking at their activity and open tickets? While the status names themselves aren't adjustable, you could create a custom ticket field that is viewable to the end-user to provide more clarity.
It is also worth noting that the end-user experience with status is slightly different than the support agent's view. More information about that is here: https://support.zendesk.com/hc/en-us/articles/360001029307--What-are-the-customer-portal-ticket-statuses-
Hope this helps!
Brandon
It's crazy that you don't allow 2 same fields for different forms. This is messing up our reporting and makes it not uniform.
HI Maurice Melvin Asuncion -
Sorry you're having trouble! Zendesk ticket fields rely on tags to help track the different options correctly.
If the goal is to have the same exact ticket field on two different forms, you can easily add that ticket field to both forms. If the goal is to have the same options in two different ticket fields, you can achieve this by utilizing the "show tags" feature within the ticket field creator, giving a unique tag to the offending value.
Form 1:
Value: Noise
Tag: F1_Noise
Form 2:
Value: Noise
Tag: F2_Noise
Then on your reports you can combine these data points into a custom metric if necessary.
I hope this helps!
Brandon
Please sign in to leave a comment.