Question
How can I add additional ticket Type options?
Answer
It is not possible to modify the native Type ticket field, as this is a system field. There are four values for ticket Type:
- Question
- Incident
- Problem
- Task
Since it is not a required ticket field, it can also be left blank.
As a work around, a custom dropdown field with more values for "type" can be used to achieve workflow. This option would allow for agents to forgo the use of the native Type field and solely use the custom "type" field. For a guide on creating custom ticket fields, please see our article on Adding custom fields to your tickets and support request forms.
21 Comments
Can you add Feature Request or Enhancement to the ticket Type field? I'd rather not add a Custom field for this purpose.
Hi Clay -
You would need to add a custom field for that. There is not a default field for feature requests or enhancements.
Hi Nicole,
I was hoping 'add a Custom Field' wasn't going to be the response.
Feature Request seems like the kind of field that would be a shoo-in for a common solution.
Is it possible that somewhere up the chain of command, someone might say, yeah, that's a good idea, we'll add it?
Clay
Hi Clay -
I know it's not the response you were hoping for, but it is how the system currently works. I know it seems like a simple ask, but it's possible that changing those fields would have other implications, or that it hasn't been included to this point for a reason.
That being said, you're welcome to start a thread in the Product Feedback area of the Zendesk Community, where the Product Managers go to hear from our customers about their use-cases. You'll want to give them details such as what the impact to your business is and how it fits in your workflow. i.e. do you get 30 tickets a day or two per month with feedback? How would having this field change your workflow? What would having that field enable you to do? Why is the custom field a suboptimal option?
Product development decisions take into account the size and scope of the impact, number of customers this would impact, cost of development and implementation, and a number of other factors. I can't guarantee anything, but posting there is the best way to get your idea in front of the Product team.
Thanks! I'll check it out. Have a great day!
You too, Clay. Thanks for your feedback and participation. :)
+1 It would be great to have a possibility to rename default ticket type values.
+1. very helpful option
Yes, it would be helpful if we can edit the type field and can add more options to the drop-down.
Thanks,
Hi all -
I encourage you to create a new post in the Support Product Feedback topic where more users can see your comments, engage, and vote on the idea.
If we plan to use a custom Ticket Field to track the ticket type due to a desire to have more granular control, is it advisable to deactivate the built-in "Type" field if we plan to not use it, or will this cause issues? Thanks so much!
Hey Chris,
Since this isn't a required field you won't have to worry about de-activating and leaving blank. If you do run into any issues please let us know and we can dig into it with your :)
Hey Brett,
Thanks for the quick response! I've gone ahead and deactivated the built-in "Type" field and created my own with the same name. So far, so good.
Thanks again and enjoy the weekend!
Happy to help Chris!
I would like to use the Problem / Incident functionality that the built-in system Type offers, but would also like to have other types available... and not have redundancy or clutter when it comes to the fields agents need to fill out. It seems like I have to choose one or the other.
Has anyone come up with a viable work-around?
Hey Joel,
I'm afraid in this case it would need to use one or the other if you want to include custom type options. Perhaps other users can come up with an alternative solution for you that I may be missing.
If the System Field is deactivated but some items have been assigned to a Type in the past, do we lose the existing reporting? For example, deactivating the Type System Field and creating a custom field for that same purpose, how can we link the existing type tickets, etc. to the new custom field?
Hey Alex,
If the tickets are closed then that data will remain available within your reports. You won't be able to edit those tickets as the fields become read-only access. For reporting purposes, you'll want to temporarily include both fields in your report until you've completely phased out the field you've deactivated.
Once you've phased out that ticket field you can remove it from your report and continue using your newly created ticket field.
I hope this helps!
Why Zendesk team does not listen to its users? Having hardcoded types does not make much sense. Each business requires a different type of tickets.
I am surprised by the fact that everything in Zendesk is hardcoded.
Perhaps you should investigate how many customers use the system Type field as is? I would guess not many.
Is there a way to make "Incident" the default value of the Type field?
Custom drop downs let you select a default. It seems like system drop downs should as well. (Blank could be selected as a default if an organization wanted agent action to be required).
I too want to leverage the Incident / Problem functionality of the native Type field. At the same time I need all new tickets to come in as "Incident" so our agents will not to complete yet another field. We have in place a custom field for the business driven types. Best I can tell these do not provide the incident / problem functionality we need to incorporate Service Desk Problem Management.
Hey James,
There's no way to make Incident the default value, however, you could use a trigger that sets the type to incident once the ticket has been created. You can use the following conditions:
Ticket > is > Created
Action
Type>Incident
More information on triggers here: Trigger Resources
I hope this helps!
Please sign in to leave a comment.