About ticket fields

Typically, when end users submit support requests, they provide the subject and description of their question or support issue. They may also be prompted to provide additional data such as a product type or model number using custom ticket fields. All of the other data in a ticket is set by you or behind the scenes using the business rules.

The standard fields that agents see in a ticket are referred to as system fields. See table below. Additional system fields are added to the ticket page when you activate additional Zendesk Support features such as ticket sharing.

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. New means that the request was received but that it has not been opened and has not been assigned to an agent. The New status can indicate that the support team is evaluating it to determine who should be assigned to resolve it. After changing the status from New to another status, you can't change the status back to New. Open means that the request has been assigned to an agent who is working to resolve it. Once a ticket status changes to Open, it can never return to New. If your tickets are being created in the Open status instead of New, see Why are new tickets being created in Open status? Pending means that the assigned agent has a follow-up question for the requester. The agent may need more information about the support issue. Requests that are set to Pending typically remain that way until the requester responds and provides the information the agent needs to continue resolving the request. On-hold means that the support request is awaiting a resolution from a third party, someone who is not a member of your support staff and does not have an agent account. This status is optional and must be added. See Adding the On-hold ticket status to Zendesk Support. Solved means that the agent has resolved the support issue. Solved tickets are closed, typically, a number of days after they have been set to Solved (the exact number of days depends on how an Administrator set this up). Until a ticket is closed, the requester can reopen the ticket. For example, the requester may not agree with the agent that the support issue is resolved and reply back to the ticket solved email notification. Closed means that the ticket is complete and can't be reopened. Requesters however can create follow-up requests for closed requests. A ticket's status cannot be changed to Closed manually. Closing a ticket is handled 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. Question is used to indicate that the requester's issue is a question rather than a problem that needs to be solved. Incident is used to indicate that the requester is experiencing a single occurrence of a larger problem that is affecting multiple users. Problem is used to indicate that the requester is having an issue with your product or service that needs to be resolved and that is affecting multiple users. For example, if the wireless network in an office stops working, the problem will probably generate several support requests. Instead of handling each ticket separately, create one ticket describing the problem and set the type to Problem. Link incident tickets to problem tickets. When you solve the problem ticket, all of the linked incident tickets are solved, too. See Working with problem and incident tickets. Task is used when you want to assign the ticket as a task to a specific agent. When you select Task, you also set the Task Due Date. The due date is defined as 12pm in the account's local timezone on the date specified. 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: You can add them manually. Tags can be added (and removed) automatically based on your business rules. Tags can be added to users and organizations and these tags are automatically added to tickets. Tags are enabled by default but can be disabled. See Enabling and disabling ticket tags.

You can deactivate and reactivate some (but not all) of the system fields and add and manage custom fields on tickets. For more information, see Viewing your ticket fields and Editing and managing your ticket fields. Some system fields are inborn and cannot be reconfigured. See What are the inborn system ticket rules?.

In addition to these system ticket fields, tickets can also contain custom fields, which are used 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. For more information, see Adding custom fields to your tickets and support request form.

Tickets contain other data that you can access using placeholders and the Zendesk API. For more information about this additional data, see Ticket data.