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.
-
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.
-
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.
-
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!
-
+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.
-
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.
-
Glad I found this before I deleted values.. We need this!!!!!
-
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. :(
-
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.
The use case above is well written out by the way. Thank you for that.
-
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<remove_cr.length; i++) {
raw_cr_options.remove(remove_cr[i]);
}
} catch (error) {
console.log (i);
console.log('ERROR!', error);
}
}); -
+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
-
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.
-
Nicole Saunders Any chance of getting this on the roadmap now? Seems reasonably requested.
-
Nicole Saunders I'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.
-
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.
-
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.
While at times, we create a calculated metric to 'marry' old and new options or mask them, this becomes cumbersome to maintain just as Chris talked about the same issue with maintaining triggers.
-
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.
-
@... Will you get this information added to a HC article? Seems like a BIG gap in knowledge sharing with your customers.
cc: Jafar Al-Hassan
-
Chris Fassano Sorry 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.
-
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
-
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.
-
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. -
Bump in case someone is sorting these by recent activity.
Would be great to have a PM to comment on this. -
Chris Fassano Any 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
Por favor, entrar para comentar.
35 Comentários