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 (Classic) for example, and to agents in a ticket, as shown here.
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.
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 complete list of custom ticket field types.
Also, 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 your 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.
|Requester||All tickets require a requester. The requester is the person who made the
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 and can be up to 150 characters. 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 system ticket status values. A ticket's status can be set and
updated either manually by an agent or automatically via your business rules.
If you've enabled custom ticket statuses, your account may include additional ticket statuses. The system ticket statuses listed below are the default ticket statuses of your ticket status categories. See Managing ticket statuses.
|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.
Note: If you deactivate the Type field, all your tickets default to Incident, which is one of the most-common ticket types.
|Priority||There are four values for priority: Low, Normal, High, and
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. If you deactivate the Priority field, Zendesk SLA targets will not apply. See Setting up SLA policies.
|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.
I wanted to comment on the task section piece and see if anyone has any advice. For Zendesk if you mark a task to be due on a certain date, the rules for that are as follows " The due date is defined as 12pm in the account's local timezone on the date specified." What if you have someone who's shift doesn't start until after 12 though? How will they be able to see these tickets in the " My tickets due today" view if they are considered past due after 12? This seems kind of silly to me and I would like to have any ticket that is marked as a task, sit in the " my tickets due today" view until after that day has ended. How can I make that happen?
Hi Megan Lalock,
I agree the due date and functionality around it can be improved. Hopefully Zendesk will do that soon! In the meantime, I would include due dates that are for yesterday, today and tomorrow and sort it by date in the View. I know this is clunky...
Sorry if I missed this. How does an emailed ticket respond to Required fields?
Thank you for reaching out to Zendesk Support.
In regards to your concern, the following ticket fields are only applied to ticket forms. This means that your customers can only interact and make changes to ticket fields when they submit a ticket request form. As long as the ticket field is editable for the end-users as well.
DJ Buenavista Jr. |
Customer Advocacy Specialist | Support@Zendesk.com
DJ Buenavista Jr., thank you for the comments. So the only option to force form usage is a triggered response asking them to log in and select a form. I assume embedding form selection/required fields into an autoreply is somewhat tricky? I would love to see an example of this.
You're more than welcome. In regards to your follow-up question, the option to use a form is shown in your Help Center. There's a Submit a Request button option from there where you customers have the option to choose a form depending on what issue or what they need.
For example, you can create multiple types of forms depending on what your customers need, for example, Billing, Support, or General Inquiry. There would be an option for them to choose what form they prefer and can answer or fill out the details of the form and then submit it as a request and it will create a ticket in your Zendesk account.
You can check our articles for more information about this.: https://support.zendesk.com/hc/en-us/articles/203661626-Presenting-ticket-forms-to-end-users-Professional-Add-on-and-Enterprise-?page=2
Thank you and have a wonderful day ahead!
DJ Buenavista Jr. |
Customer Advocacy Specialist | Support@Zendesk.com
DJ Buenavista Jr., my issue is when they utilize the email channel. Everything works perfectly if they log in to the portal and submit a request.
I am trying to force users to fill out the form and looking for the best practice in getting them to do so. Is it simply a reply suggesting they log in and fill out the form? Or, can we embed the form into the reply and say you must populate the required fields and hit submit, or the ticket will not be opened?
Customers can only use ticket forms in your Help Center. If you want to embed a more complex form or that option, you can create an HTML form. For more information about this, see the article: (https://support.zendesk.com/hc/en-us/articles/115012037228-Options-for-letting-end-users-submit-tickets-with-forms)
DJ Buenavista Jr. |
Customer Advocacy Specialist |
Is it possible to expand the size of the sidebar to better view the ticket field information?
Is it possible to convert the ticket fields to an internal note, automatically?
It's not possible to resize the width of the ticket fields sidebar.
It's possible to create a macro that will display the values of certain types of ticket fields (checkboxes, dropdown fields, and multi-select fields), using the / placeholder. See Creating macros for tickets and Using placeholders for custom fields. Other custom field types are not supported, however.
Can you tell us a little more about your use case? What kind information are you wanting easier access to?
The use case is specific to viewing details of a submitted ticket. we collet a lot of information for internal requests via Ticket Fields. It would be optimal if the sidebar was larger to allow for a easy to read experience. Rather than cutting text off, or having to hover over fields.
We have found we can manipulate the CSS to achieve a larger sidebar this but that is specific to a machine.
I was curious if it is possible to format the description or internal note, with the contents of the ticket fields to provide a better view of the submitted information. Does this make sense?
Can I use the same ticket field more than once in the same form? And if so, how?
Not natively, no. What use case are you solving for?
I had a use case in an ecommerce situation where I wanted to have the tracking number for different parts of the order. Turns out having separate fields for this made automation, notifications and other things much easier. We ended up with Tracking1 Tracking2, etc.
I have only had one ticket form, a very simple one.
I'm creating my second. I created a bunch of new ticket fields and then added them to my new form (which is currently agent-only, until I'm ready to unveil it.)
When I went to go check out our current default ticket form (as an end-user, not signed in), I was shocked to see that all my new fields had been added to that form additionally! I quickly went in and removed all of those ticket fields from that form... but I had not added them there in the first place... it can't be that any new ticket fields created which are "editable for end users" are added to all existing forms, can it?!
Ohhhh, I found the answer to my question from here: https://support.zendesk.com/hc/en-us/articles/4408883152794-Adding-custom-fields-to-your-tickets-and-support-request-form
Now that I have my second form created, this shouldn't happen again.
As far as usability go, it would be great if it would have given me notice or a warning that I was creating a field that would instantly be live on my existing form. I had a couple of conditions, so I'm sure that the new fields initially all showed up before I had the chance to set up my conditions. What a mess. Thankfully ticket volume is very low right now; I don't think anybody saw it.
Anton, perhaps I'm missing something obvious here, but: is Requester still one of the default ticket fields? If so, how can I find it to include it on a ticket form?
We've recently set up a ticket form for use in our Help Center, but I do not see Requester, Name, or similar field in the list (see below). We added "name" as a custom field -- but this does not, of course, populate the name field on the end user account, so it's less than ideal.
If there's a way to include the name of the requester on a ticket form that the system recognizes a name, could you explain how to add this?
Hey Liz W -
Happy to help here! Requester is a system field, so it doesn't visualize in your ticket fields and forms. There are two different experiences that users will experience when attempting to submit a form on your help center. Unauthenticated users who attempt to submit a ticket will be presented with an E-mail field automatically (which maps to the requester field). While you can ask these user's for their name, that data will unfortunately only populate to the ticket, not the user profile.
For users who have taken the time to log into your Help Center, we don't need to ask them for their email address (because Zendesk already knows who they are). In this case, the email address associated with their login automatically becomes the requester, and their name is most likely already known as they have a profile with you.
Finally, for Agents creating tickets on behalf of end-users, when they enter the agent workspace and create a ticket, the requester field will be blank, allowing them to either enter an existing user's name / email address or create a new user if the profile doesn't exist in your system.
Let us know if you need anything else!
OK, that answers my question. Thanks, Brandon!
I was thinking primarily about the scenario of an unauthenticated user submitting a ticket via our Help Center ticket form - that is, a "cold" ticket from someone not already in our system. From what I'm seeing in testing this out, the email they use will then be listed as both the "primary email" and the user "name" in their end user profile. And from what you've said, there's no way to include a field on our ticket form that would automatically populate the user name section of the profile with their name instead of the email. Correct?
Hi Liz W -
That is correct.*
* Depending on how critical of a need this is, you could employ the use of a webhook and the Zendesk user api / JSON to Trigger an update to the user profile, but this is a fairly advanced work around.
I would also encourage you to leave product feedback section of our Community.
Hope this helps!
In a ticket form, I would like to insert a block of text in between ticket fields, standalone, as opposed to being just part of the "Title shown to end users" or "Description shown to end users." It would be like a new ticket field type - one that doesn't request any kind of response but is just a block of text (or an image, or something like that.)
I can file this as a feature request if it doesn't exist, but does anybody have a workaround for this in the meantime?
Is there a way to get the ID for Requester, Primary email and organisation?
You can use the show user endpoint to obtain that information from a ticket. For more information about this, see the article: https://developer.zendesk.com/api-reference/ticketing/users/end_user/#show-end-user
Is there a way to hide the custom fields on user ticket if they are empty (end user has not entered the details as they are optional)? We want to show only those custom fields to the agent which are filled up by the end user.
I don't know that there's a way to do that specifically, but if you have a lot of ticket fields and want to cut down on the number that show up on any given request, then Ticket Forms or Conditional Ticket Fields might be of use to you.
I have been trying to create multiple users from a ticket. One of our forms requests two unique emails and user information. I was originally hoping to use triggers to create users but that does not appear to be an option. Requiring all ZD originating emails to only send to users is limiting because creating a user every time we want to respond to this form is obnoxious. We can't ask them to enter the emails as a CC because we need to apply their first and last name when we create their account in our software. We process dozens of these requests a week and creating users adds time back that we were going to save with our switch to ZD. Does anyone have a clever work around?
Hi Jasmine Winzeler,
The available options for creating a user in Zendesk are listed here: How can a user be created in Zendesk?
I am afraid that at this time, it is not possible to achieve the workflow you are looking for. Having said that I would implore you to share your use case as Product Feedback here with our Product teams. Providing feedback helps grow Zendesk alongside our customers needs and ultimately one day your idea could be implemented into the UI.
Hey Jasmine Winzeler - you might be able to do something with Zendesk's webhooks feature for this.
When a ticket is created and these secondary user fields are filled, you could have a trigger send a message to a webhook that passes in the field information. You can have that webhook create a user in Zendesk if they don't exist, and if your product supports receiving webhook events of some kind, potentially do the same.
There's probably be some edge cases you'd need to iron out, like what if an email already exists, does it overwrite names, org memberships etc.
As Nikki and some others asks already,
an additional field type of something like static info text
(including the option for HTML links e.g. for a legal notice) would be nice to have...
Please sign in to leave a comment.