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.
-
Thanks for the detailed feedback, Chris!
We'll continue to collect votes and comments on this suggestion to gauge other users' need/interest as well.
-
I agree with this suggestion. The biggest problem is that I can no longer report on values if I remove them. I still need to report on the old activity.
-
I too would love to see the ability to inactivate field values. As we continue to grow and review our current values, we often find that we can consolidate problems into fewer problem types. It would be nice to have the ability to hide the values we no longer need and still be able to report on the older data.
-
Glad I found this before I deleted values.. We need this!!!!!
-
+1 for this functionality. Reporting is critical and we need a way to report on values that were once used but no longer used.
-
Please implement this functionality. We really need this.
-
We also need a functionality to deactivate drop down field values.
It's a must have for longterm Zendesk users with changing values from time to time. -
This could prove insanely useful to our firm.
-
The ability to deactivate fields is becoming more and more of a necessity as time passes. Please make this a priority as it's becoming very time-consuming to manage this.
-
2 years since this was opened.
All ticketing systems have this option only Zendesk does not.
The fact that Zendesk is not doing anything about such important option is mind blowing.
-
Zendesk PM Team,
Can you please share a roadmap/timeframe when this feature is planned to be implemented?
Also, other than the input/comments already shared on this thread, how can the Zendesk community help influence this feature to be prioritized higher?
Thanks!
-
This is a huge issue for us. We just had a vendor name change so that value in the drop down for vendor has to change. I would want to keep the previous value but not allow the user to continue to select it on new tickets. Instead, I tried changing the value on the drop down and it deleted all the previous values. :(
-
Nicole SaundersAny chance of getting this on the roadmap now? Seems reasonably requested.
-
Hi Abed - I'm not the product manager, so I'm not the person who can make that decision.
The way these forums are used by our product teams is that they read through all of the requests, and look for common issues, patterns, and use-cases across all of them. When they do their quarterly planning they take the conversations from the community into account alongside other factors such as feedback we've heard through other channels, the long-term plans for the product and how an individual request fits into that vision, what the technical lift is and how much other work would need to be performed in order to enable a given feature, etc.
I'll flag this conversation for the product team, but I'm not sure where they're at with their planning cycle, so it may be another few months before they'd be able to evaluate it and comment. -
Nicole SaundersI'll upvote this thread. As someone newly implementing Zendesk, I was very surprised not to see this feature available and it made the implementation that much more difficult. We will undoubtedly be changing our ticket issue categories as we learn and evolve.
The workaround which we've preliminarily tested is to make sure all tags related to issue types are set up a particular way - so "_cat" at the end of each tag so that in future reports, we pull the old issue types in as well. The tag at least seems to remain with the ticket, even if the value is deleted.
-
Bump in case someone is sorting these by recent activity.
Would be great to have a PM to comment on this. -
I am running into this just now as well. Specifically for the product example that he gave. I don't think the right scenario should be having to have extra unnecessary fields to track this properly for historical data purposes.
When a product goes away, you need to ensure users aren't still setting things to that product. But as a business, you need that historical data.
-
This is a problem for our company as well. Being unable to report on deleted values is causing issues in our historical data and is immature behavior for a product like Zendesk to be honest. I hope we can have this functionality soon.
上面的用例写得很好out by the way. Thank you for that.
-
I received word that this is not on the Zendesk roadmap.
-
I wholeheartedly agree with the need. Our Explore reports are 'ugly' with the tags that display for drop-down options that have been deleted.
而有时,我们创建一个度量来计算的marry' old and new options or mask them, this becomes cumbersome to maintain just as Chris talked about the same issue with maintaining triggers.
-
Chris FassanoAny chance I could how you setup the triggers? Looking to do the same thing.
Currently, I have it as:
Meet ALL of the following conditions
- Drop down value from the visible field is X
- Drop down value from the invisible field is not Y
Action
- Drop down value from the invisible field is Y
Not sure if I have to add a "Ticket is updated" clause or if this is fine
-
Salim Moumouni- I use the "Ticket is created" condition. You would only want to use "Ticket is updated" as a condition if you want the trigger to fire for updates that occur after ticket creation.
Meet ALL of the following conditions
Ticket is created
Webform product field is Product AAction
Internal facing product field = Product A -
I too would like the ability to deactivate values in custom fields instead of deleting them. A team member recently updated a field value. I'm guessing that means I cannot get data associated with the old field value. I have a workaround of placing an X or OLD before the "archived" field value but as previously mentioned this will get cumbersome. It's disappointing to hear that Zendesk has no plans to fix this.
-
Not sure why none of the moderators recommended this app or why none of the HC content writers or managers have included instructions on how to use this app, which was built by ZD?
我们使用这个程序//www.ying8.net/marketplace/apps/support/223753/ticket-field-manager/to hide picklist values we no longer want agents to use. Works well..
-
Thanks for sharing this, Jay!
-
Molekule——我们使用这个程序,但这只是对你好ding field values from agents. It doesn't hide field values from customers on the ticket submission form. This is why I have two product fields. One product field for the ticket submission form that only contains the current values. The second product field thats visible to the agent and contains all current and historic values. The ticket field manager app is configured to hide values on the second field that would otherwise be deactivated.
For each of the field values on the first field, I have a trigger that sets the corresponding value on the second field.
-
@...Will you get this information added to a HC article? Seems like a BIG gap in knowledge sharing with your customers.
-
Chris FassanoSorry to hear this doesn't solve your problem... Not sure why ZD hasn't prioritized a solution for this...
-
The issue continues to grow for our team. We cycle through products often.
-
Hey everyone! My team has a custom solution to this problem. We have custom fields in our ticket submission form, and we also have some values that we don't want to display to our users.
In the following code block the value in pointer1=$('.request_custom_fields_+field_id) is the class assigned to the dropdown div. Replace "field_id" with the id of the dropdown you wish to hide values in.
Replace the the "tag" values in the private_options array, for the values that you wish to hide in the dropdown, you can find these by going to the field in Zendesk Admin page. (It must be the tags and not labels).
It's not a beautiful solution, but I hope it helps someone out there!/*---------------------Function to restrict contact reason fields------------------------------*/
var pointer1=$('.request_custom_fields_'+field_id).children('a').attr('aria-controls');
var skip1='#'+pointer1
$(skip1).on('DOMNodeInserted', function(e){
var nesty=$(this);
//get all cr values
var raw_cr_options=nesty.children('ul').children();
var all_cr_options=raw_cr_options.map(function(cr){
var li=raw_cr_options[cr];
var id=li.getAttribute('id');
return id;
});
var private_options= ['outage_notification', 'infrastructure_notification']
//filter for only the desired values
var remove_cr=all_cr_options.filter(function(cr){
var li=all_cr_options[cr];
return (private_options.includes(li));
});
remove_cr=remove_cr.map(function(cr){
var li=remove_cr[cr];
return ('#'+li);
});
remove_cr=Array.from(remove_cr);
try {
var i;
for (i=0; i
raw_cr_options.remove(remove_cr[i]);
}
} catch (error) {
console.log (i);
console.log('ERROR!', error);
}
});
Pleasesign into leave a comment.
35 Comments