Deactivate field values instead of deleting them
What is the problem?
I have custom drop-down fields, like product and root cause, that contain values that have become outdated. If a field option becomes outdated and I want to remove it from the drop-down list, I don't have an option to disable the field value other than deleting the field value.
Why is it a problem?
Since I use a third-party reporting tool that allows us to store data from Zendesk and our other systems in a central location, It's important that I don't delete these legacy drop-down field values. I've found that when a field value is deleted, our reporting tool is no longer able to associate the values tag with the drop-down field where it previously existed. This means reporting against legacy values becomes very difficult.
Deleting old values from a drop-down field also makes it difficult to have a full understanding of what values were previously configured under that drop-down field. I would have to maintain a list outside of Zendesk.
How I solve the problem today.
In order to maintain these legacy values without deleting them, I had to get creative.
For example, we now have two product drop-down lists: (1) a product list that's visible on the help center ticket submission form which contains a list of currently supported products; (2) a product list that contains all products, legacy and supported products. The second product field is only visible to agents.
For reports that reference the product field, we report against the second product field which contains all products.
To make sure a ticket has the appropriate product selected on the second product field (the field used for reporting) I created a series of triggers that updates the second product field when a value is selected on the first product field.
This method has worked fine for the product field because the list of values is relatively small. But now I've received requests from management to update drop-down fields that contain a much larger list of values (ie root cause). Using triggers to sync two root cause fields would be very cumbersome and time-consuming.
How I would ideally solve the problem.
Each value in a drop-down field has an option to be flagged as inactive. The value would still exist under that field but only visible from the admin menu and API queries. Flagging the value as inactive would hide the value when viewing the drop-down field from a ticket form for both agents and end users.
How big is the problem?
Maintaining data and building accurate reports is a high priority for our organization. Adding/removing values from ticket fields is already an issue that requires careful consideration. Making it more complicated by having to dance around field configuration limitations makes it that much more difficult. It is an issue that's very high on our list of things that we think should be improved in Zendesk.
-
This is a pain. As OP states, removing fields will destroy your Explore reports, and looking at old tickets, will give a bad UX.
We use a custom private app to hide some fields in Zendesk Support as a workaround. Not great to maintain, and really should be built into the product. Our workaround only works because we don't use guide or built in web widget, the workaround would become very complicated if use those.
Zendesk, this is a hard problem for you customers to work around.
Would love for this to be prioritized.
Part of Zendesk's USP is building powerful solution using custom fields, yet we lack this basic support for maintaining the lifecycle of our custom fields.
I have no idea why this is not yet in the product. Is the request not "sexy" enough? AI is cool, but I also want Zendesk to nail the basics.
-
A native feature to deactivate fields values is essential, I'm using "Ticket Field Manager" app but with multiple ticket forms isn't a good experience because the hidden values return if you switch them
-
+1 for this. We are a software company that uses a drop-down field to track Product/Module type data. We would love to deactivate legacy items without losing historical ticket data. Please can we have this. Thanks!
-
+1 for this
-
Not sure why/how this hasn't be addressed. If there was a way to merge tags used historically, then that would at least be a workaround, but no dice. For frame of reference, JIRA components are allowed to be deactivated, which is similar to what would be custom field usage.
-
Agree this should be an option to inactive sub-fields. Also, what happens if you rename that sub field? Does that change the past naming conventions or no?
-
Hi there,
I believe that closed or archived tickets should not be updated if you change the field.
Best,
댓글을 남기려면 로그인하세요.
37 댓글