Recent searches
No recent searches
Deactivate field values instead of deleting them
Posted Jan 23, 2019
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.
82
39 comments
Joel Hellman
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.
3
Leonardo Santos
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
Predz (StarRez Inc.)
+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!
2
Anastasia Kachanova
+1 for this
2
Jimmy Rufo
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.
1
Tattie Petts
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?
1
Tony
I believe that closed or archived tickets should not be updated if you change the field.
Best,
-2
Marcus Vickers
I would also like to see this functionality incorporated. I have a request right now to deprecate some old values that aren't being used any more and have no solution to do so safely.
1
Ashwin Raju
Here's an alternate solution for this use case. Let's the example of a Product catalog. Product A and B are active and Product C is discontinued.
1) Create a Custom object called Product, You already have the Product Name field created for you. Add a checkbox field called Active.
2) Set the permissions to read only for Agents. We have a new feature coming next week (to hide the list view of custom objects). This will help you to hide the list view of Products, so that your agents are not distracted by this list. On the contrary, it could be useful to know if a product has been deprecated.
2) Upload all your products into this object.
3) Create a lookup field in a ticket that points to Product object. Add a filter in this lookup field to only show Products that are Active
When you go to the Ticket, your agents will only see Product A and B .. But not C. Tomorrow, you want to add a new product - add it to the product table and it will automatically show up in the tickets (as long as it is active)
The main advantage of this approach is the scalability and manageability of this data. You can bring in much more than 2000 products into the list (you can in fact go into the millions). You can in fact assign this responsibility of keeping this data correct to the Agent Managers or someone in Ops.
Having said that, I do realize that this solution does not work well when you already have a drop down and want to have the same behavior in the drop down so that your reporting doesnt get affected. But it is definitely worth considering making the switch if this is a non-negotiable use case.
I will anyhow add this feature as a feature request into my backlog. But given my currently backlog, it doesnt seem like we'll be able to work on it this year.
0