You might have noticed that drop-down fields and checkbox fields have associate tags attached to their options. Knowing how these interact will give you a greater understanding of the platform and a better idea of how to set up your workflows. For more information on tags see, Using tags.
This tip covers the following sections:
Understanding tag and ticket field interactions
- When you select a field option, the associated tag will automatically be added to the ticket.
- If you add a tag, the associated field option will be selected as well.
Basically, when Zendesk Support tries to populate fields, it looks for tags on the ticket first and then selects the associated field options for those tags. This is why you cannot have duplicate tags associated; the system won't know which field option to use. To prevent this, you will receive an error when you try to use the same associated tag.
This tag and field option relationship causes the following results:
- If you add a tag that is associated with a different field option, the new option will be selected and the original field option's tag will be deleted automatically.
- If you rename a field option, all tickets with the associated tag, including closed tickets, will be updated with the new name.
- Deleting a field option will change the ticket field to 'null' in all tickets with the field option. If you re-add the option, along with the same associated tag, then the ticket field will be selected again automatically.
Changing the field option tag
If you change a field option tag, there will be different repercussions than when changing a field option. For example, you can change the field option title with little repercussions (aside from reporting), but you cannot change the field option tag with the same results. Since the tag is the backbone, if you change the tag, you will create a new field option.
Changing the tag will result in the following behavior:
- Changing a field option's tag will automatically deselect that option from all tickets with the field selected.
- If you change the field option tag to a tag that does not exist on a ticket, the field will revert to a 'null' value.
- If you change the field option tag to tag that does exist on a ticket, the field will revert to a 'null' value until an update occurs. After an update, Zendesk Support re-reads the tags and will select the correct field option.
- Since you need an update to populate the updated field option, you cannot change field option tags to edit closed tickets.
Note: The only exception to this rule is if your field option was deleted and then re-added into the same field (as discussed above). You cannot create the same field option in a different field and expect the results to populate historical tickets.
As you might imagine, this can become especially messy when you delete field options or disable/delete entire fields. Remember, data is important. Once it's gone, you'll never be able to get it back.
We have a field with values that do not match up with the corresponding tag. At some point, our team updated the field values without reviewing tags, so there are mismatches between the two. This is making our reports on this field confusing because the tags are completely different than the field values.
What I am wondering is how we should go about making the update to our tags so they align with the field value. My understanding from this article is that we will lose the historical data if we simply update the tags to better align with the field value. Is this accurate? Is there any way to keep the historical data based on the field value itself?
If you're using Explore, you can create a report solely based on the ticket field value, regardless of the tag that it's associated with. Assuming that the correct values were still selected in your tickets (even if if they were associated to an incorrect tag), they should still show in Explore. Here's an article about this - Reporting with custom fields. In other words, as long as the correct value in the ticket field is being selected in your tickets, then Explore should reflect these values.
I understand you're planning on correcting the tag associated with the ticket field, however, you are correct in saying that this could further skew your data, especially for your already closed tickets. Changing the title/value of the field to align with the tags will change the values shown in the ticket and in the Explore data I showed above. On the other hand, moving the tags around for dropdown fields will also cause data to be changed as well (i.e. the actual ticket field values will change depending on the tag).
If you plan to do this, I recommend reviewing this article first to emphasize its impact - Understanding how creating, deactivating, or deleting ticket fields impacts tickets
If I understand well, there is no way do "disable" values in a drop-down list, so that we may change the proposed values at ticket creation without loosing historic data?
What we want to do is : continue using the same field, but propose some new values to our customers, that better fit our needs and their understanding. At ticket creation, we would like our drop-down list to display only the new values, and not show the old ones. But we don't want to loose data from old tickets. How do we do this ?
Hi Emmanuel Lepessec,
What I've done in the past is change the name of the option but left the tag alone. In this way the old values will be merged with the new values because really the tag dictates it in reporting.
Only do this if the intent of the value is the same!
Thank you for your reply. :) Yes that could be a solution, but unfortunately our old values are really too different from the new ones... This is particularly a problem on one of our lists which contains far too may options for the moment, and we want to reduce the number of choices.
I think we don't really have the choice: we will need to create new fields, and make the current ones "agent only", so that they appear only in the backoffice.
But, as we also need to synchronize with another support platform from one of our partners, and as we don't want to ask them to create new fields either, this causes us another problem...
Our situation is not simple... :)
Still stuck... I don't want to change the values nor the tags in thousands of existing tickets, where I have quite a lot of them still open. I would like to propose new values though, to better qualifiy my tickets, so I thought I would start using new fields. But how to handle transitions between "old" tickets and "new" ones? I have to make my new fields visible in order to use them, but I can't hide the old ones, as they must still be seen by my customers, at least till their tickets are closed. Which results in a quite confusing display...
I just can't figure out how I could solve this in a simple way...
Hi Emmanuel Lepessec
Just a suggestion and something you may have already tried. Have you thought about using triggers?
If ticket less than solved, ticket updated and tag = old_tag
new field --> new item
This would update the customer fields from old to new. This assumes that the new fields are representative of the old fields.
Can you add more than one tag in the checkbox field (field option section)? If so, how do you enter multiple tags? Thanks
There could only be just one tag associated with a checkbox field.
If you need to add more tags, I would suggest creating a business rule that would place an additional tag/s on a ticket if the tag associated with the field is present.
Is there any way to turn this functionality off? We don't need this for all of our fields, for example we have picklist fields with yes/no answers so we don't need "yes" and "no" saved as tags.
I definitely understand your use case for this. However, it is by design and cannot be disabled.
Anyway workaround in order to assign tags to a free text custom field ?
Our field would be something like : Customer Name. It would be great to be able to automatically assign a tag as : customer_name_XXXXXX
We just found out that there's an update on the ticket field/tag rule and it's really bothering us - we can no longer use slash (/) for our ticket tags. However, there are several tag we've been using for years which contain slash, removing the slash now will affect our data and make it really difficult for us to keep tracing certain tags.
Is there any way to rectify this or if we could setup something to make the system automatically recognizes the two tags (with slash or with out slash) as the same one? Thanks!!
Are you referring to the tag in the custom ticket field? If so, then I checked this and I'm not getting any errors using "/" and I was able to save this without any issues.
Looks like we're only receiving this error message on 5/9, not sure if there's any change in the system or not, it's now resolved, thank you!
We haven't got any reports of any issues last 5/9, but it could have been a minor hiccup or issue. I'm glad to hear that everything is working now.
Please don't hesitate to reach back to Zendesk Support if you have encountered the following issue again.
Have a great day ahead!
Given that changing the ticket tags wipes the ticket field selection from all tickets, the recent change the ticket field UI to automatically edit the tag when you edit the ticket field name is a big mistake. This change makes it very easy to accidentally wipe data and Zendesk should revert this change.
The rest of the changes to the ticket field UI look great, though.
I've been having trouble with this because we don't necessarily need the custom fields to be updated when a ticket is tagged, it is affecting our flows and preventing us from creating reports on important metrics, it would be great if custom fields could be manually updated by our agents only, but we don't have this option at the moment.
I think that ideally, fields shouldn't be auto-updated or changed, or cleared because of tags, unless there's a trigger.
I am getting the error: The tag 'other' is already used in a custom field drop-down, multi-select or checkbox.
This is expected when attempting to add a tag that is already in use in an org.
My question is: what is the suggested method to finding where a specific tag is used? scanning every field in an org is not scalable and the tag is not visible in the 'top 100' tags.
There's no native way to determine where the tag is being utilized. However, you can use List Org API or List Ticket Fields API to perform a call and manually search for the tag.
Refer to the screenshot below.
I have used Postman to initiate the Ticket Fields API call. Once the list has been extracted, I manually searched for the smstag tag and I was able to identify which ticket field is using it. You can use the ticket field ID and search it on the Ticket Fields section in the Admin Center.
Please sign in to leave a comment.