Deactivate field values instead of deleting them

39 Commentaires

  • Hillary Latham

    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.

  • Bob Schackner

     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.

  • Gui

    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?


  • Reshma Patel

    +1 for this functionality.  Reporting is critical and we need a way to report on values that were once used but no longer used.  

  • Leonardo Gonçalves Flores

    Please implement this functionality. We really need this. 

  • 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. 

  • Mark Dunkley

    Glad I found this before I deleted values.. We need this!!!!!  

  • Margaret Boisvert

    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.  :(


  • Paulina Adams

    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.

  • Raul Daniel Trejo

    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 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));


    var li=remove_cr[cr];

    return ('#'+li);



    try {

    var i;

    for (i=0; i<remove_cr.length; i++) {



    } catch (error) {

    console.log (i);

    console.log('ERROR!', error);


  • 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!

  • Anastasia Kachanova

    +1 for this

  • Florian

    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.

  • Greg Padden

    This could prove insanely useful to our firm. 

  • Luke Hutchings

    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. 

  • Jiri Kanicky

    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.

  • Abed Islam

    Nicole Saunders Any chance of getting this on the roadmap now? Seems reasonably requested.

  • Aleena Khan

    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. 

  • Reneé Lasswell

    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.


  • Chris Fassano

    I received word that this is not on the Zendesk roadmap.

  • Jamie Noell

    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.

  • Elizabeth Churchill

    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.

  • Jay K

    @... 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

  • Jay K

    Chris Fassano  Sorry to hear this doesn't solve your problem... Not sure why ZD hasn't prioritized a solution for this...

  • Luke Hutchings

    The issue continues to grow for our team. We cycle through products often. 

  • 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

  • Jimmy Rufo
    Zendesk Luminary

    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.

  • 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?

  • 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.

  • Ashwin Raju
    Zendesk Product Manager

    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.


Vous devez vous connecter pour laisser un commentaire.

Réalisé par Zendesk