When using custom ticket fields, there are different actions available. Each of these actions affect tickets and the API differently.
This support tip will discuss the results of performing the following actions:
- Deactivating custom ticket fields
- Deleting custom ticket fields
- Creating new custom ticket fields
- Altering drop-down field options
Deactivating custom ticket fields
This section will describe the effects of deactivating custom ticket fields. Any data lost from the deactivated field can be recovered again by reactivating. After re-activating, the custom field will be available in the ticket view of the agent interface again.
- Closed and archived tickets: Deactivating ticket fields will alter Closed tickets. The ticket field will no longer appear in the ticket form in the agent interface.
- Unclosed tickets: The ticket field will no longer appear in the ticket form in the agent interface.
- API : The data in the custom ticket field remains stored in the ticket audits endpoint below. For more information on ticket audits see, Ticket audits in our developer docs.
GET /api/v2/tickets/{ticket_id}/audits/{id}.json
Deleting custom ticket fields
This section will describe the effects of deleting custom ticket fields. If you delete a custom ticket field, you will not be able to recreate or recover the field or its data. If you would like to preserve the field data, it is recommended to deactivate the field instead.
- Closed and archived tickets: Deleting custom ticket fields will alter Closed tickets. The ticket field will no longer appear in the ticket form in the agent interface.
- Unclosed tickets: The ticket field will no longer appear in the ticket form in the agent interface.
- API: If a field was deleted, its data, including the field ID, is saved in the API. The ticket audits endpoints tracks and stores every change to a ticket, including custom ticket field data after the field itself is deleted (see Ticket audits ). This is the only location deleted custom ticket field data is stored.
Creating new custom ticket fields
This section will describe the effects of adding new custom ticket fields. For information on creating new custom fields see, Adding custom ticket fields to your tickets .
- Closed and archived tickets: Creating a new custom field will alter Closed and archived tickets. The new custom field will be added to the ticket form in the agent interface. It will display a null '-' or empty value depending on the type of custom field.
- Unclosed tickets: Creating a new custom field will alter tickets set to any status less than Closed . The new custom field will be added to the ticket form in the agent interface. It will display a null '-' or empty value, depending on the type of custom field.
- API: The newly created ticket field only alters less than Closed tickets, if a value is added to the field. If the new field is added to a ticket form, but data is never added to the field, it will not appear in the ticket audits. This is true for all tickets with custom fields but no data added, regardless of when the fields are created.
Altering drop-down field options
Drop-down fields display the same behavior as other custom ticket fields in tickets, Insights, and the API. However, drop-down field options can be changed and edited.
It is important to note drop-down field options are directly connected to their assigned tag. For example in the image below, the option 'red' is connected to the tag 'color_red'.
This section discusses the following ways to alter drop-down fields:
Deleting drop-down field options
When you delete a drop-down field option, your tickets are affected in the following ways.
- Closed and archived tickets: If an option is deleted from a drop-down, but the drop-down is still active, Closed tickets will display a yellow caution sign and a 'Missing field value' warning.
- Unclosed (including Solved) tickets: The drop-down will change to a null '-' value, but will not display an error in the ticket.
The tag from the drop-down field is not deleted from the ticket tag field, so you can still use it in your reports. This also means if you recreate the drop-down field option with the exact same tag, the ticket field will change back to the selected value.
To delete a drop-down field option
- Click the Admin icon (
) in the sidebar, then select Ticket Fields. - Click the ticket field that you want to delete.
- Under Field values, click the cross icon (X) besides the value to be removed.
- Click Save to finish.
Changing drop-down field options
Changing the field option title but not its tag, effectively replaces the old field option as opposed to creating a new option. Reusing tags for new fields is not recommended as it will replace the existing title value on all tickets (including Closed) and could skew reporting.
The inverse of this is also true, if you want to edit an existing drop-down field option title, you can ensure that the name is replaced in all instances by keeping the same tag. This can be useful for reporting if you only want to report on a new title, not a new tag.
To change a drop-down field option
- Click the Admin icon () in the sidebar, then select Ticket Fields.
- Click the ticket field that you want to change.
- Under Field values, click the value you would like to have its name changed.
- If you want to change the tag associated with the field value, then click Show tags just under Field Values.
- Click Save to finish.
- Macros
- Views
- Triggers
- Automations
If you have any of these that look at the custom field being edited, know that the tag must remain the same in order for your object to continue to function. If the tag no longer exists for a given field-value, the object will give you an error.
Comments
17 comments
The ability to archive or hide a field option would be great. We have changing products, for example, and rather than the delete or alter options we would like to see the ability to hide an old product name (looking at you "Flash SDK") from the drop-down list on new tickets, but have it remain in the system and in the values of older/closed tickets.
How can I delete the Field value ' - ' that is added in the drop down field as one of the values? I want the Field Values to only include 'yes' and 'no'. Thank you!
Hi Paolina!
To the best of my knowledge it's not possible to remove that placeholder, since that's what the field sits on before a user makes a selection. Otherwise it would default to one of your values and could result in incorrect reporting, or business rules firing incorrectly.
Are you having a problem where people aren't making a selection in one of your fields?
Hi, I've created a dropdown field, with a few options to select. Now I know there is an option to create a dependent dropdown field for each option, but for some reason I can't find it.
Can you please point me to the right location? the goal is to select an option from the dropdown custom field i created, and it will open another dropdown option.
Thanks
Hi Itamar! Welcome to the Community!
You have two options here. You can use the existing dropdown field functionality and organize them so they have nested options: Organizing drop-down list options
Or you can use our Conditional Fields App, which will do exactly what you're describing. Bear in mind that this app is a paid add-on for the Professional plan, but is included on Enterprise.
Hello
I created a drop-down field called "Category"
When a category is assigned to the ticket automatically a tag is added; when category change (by trigger or macro or manually) the old category tag is cancelled and replaced with the new one.
i would like to know if possible to add the new tag without deleting the old one to have the history of the category tags in the ticket.
I would like to use also those tags to create a report.
Thanks and regards
Sonia
Hi Sonia!
When you change a selection in a drop down field, Zendesk automatically changes the corresponding tag to match. You could probably set up a series of triggers to re-add the previous tag, but it would likely be pretty labor intensive to create the triggers for each option combination.
Can you tell me more about why the category would be changed, and why you want to report on the old/incorrect category value in a ticket that has had that field changed?
Hi jessie
We create some triggers that categorize the ticket received from customer automatically then the ticket category can change during his life due to many factors customer send a ticket but inside it they ask us more than one info).
For example the customer send a ticket containing availability, price of a new product and with the same ticket ask us the delivery of one of their order. Therefore the ticket will be categorized as price request and then will be assigned to the agent in charge of availabilty and tan to another agent to reply about the delivery of their order
In this case the ticket will pass from price request category to availability category to order category.
We would like to report on all the categories applied to a ticket to be able to track how many request we managed on each category
Hi Rebecca! Thank you for putting together such a great article.
We are about to completely revamp our "Category" and "Reason" ticket fields. We would still like to pull reports for historical data after we make these changes.
Could you please provide best practices on how we should make these changes?
Thank you!
Hi Jessie-could you help me out with this request? Thank you!
Hey Patrick!
Are these both custom fields? If so, I think you could get away with renaming the old fields (maybe something like "Category - Old") and removing them from your ticket forms. Then you can replace them with brand-new "Category" and "Reason" fields with the new format.
I've also asked our Community Moderators to weigh in on this for you; they should have some good information on potential pitfalls to watch for.
Thank you so much Jessie!
These are custom fields. Based on your advice (and some other advice we received directly from Zendesk support :) ), we are going to:
1. Deactivate these two fields.
2. Create two brand new Ticket Fields.
Does this sound like a good set of next steps? Will this ensure we can pull historical data on older fields.
Thank you again!
Hi Sonia,
From what you are describing I believe it would be better to use a multi-select field rather than a dropdown field. That way your customer or agent can select multiple fields regarding the specific request. Also each of your tickets may have more then one of the category tag and you can then report on those tags and find out exactly how many requests came in for each category.
You can find out more information on Multi-selct fields and how to report on them in this article: New ticket field type: Multi-select
Hope this helps :)
Hey Patrick!
Yeah if you're wanting to keep historical data on those fields for use in reporting, you will for sure want to deactivate them rather than deleting anything. It sounds like you've got yourself on the right path now, but feel free to reach out if there is anything further we can help with!
@Patrick
I vote for renaming your current fields and yes deactivate them.
In your new ticket fields, i suggest paying extra special attention to the tags associated with the selections. They have to be different than the old tags on the old fields.
Also for any tickets in flight you want to update them to the new fields after new fields are in and before full deactivation. This way you can easily create a couple views and use multi-ticket update.
To remember the date you switched over, consider renaming the old fields oldthru06182018_Category or something
Great job thinking through this!
Why when I set a drop down as mandatory and with a default value, is there still the option for the user to select '-' ?
How can I remove this?
Thanks
Dave
Hi Dave, thanks for your post! The "-" is the system null value, and there is no native way to prevent this option from displaying in the drop-down field. That said, as long as you have the "Required to submit a request" feature enabled, the end user will still need to select a value besides "-" before they are able to submit the request.
Please sign in to leave a comment.