Deactivate field values instead of deleting them

投稿日時：2019年1月23日

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.

41件のコメント

日付

Raul Daniel Trejo

2022年8月31日

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

}

});

Joel Hellman

2022年11月23日

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.

Leonardo Santos

2023年1月23日

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

Predz (StarRez Inc.)

2023年2月17日

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

Nina

2023年4月19日

+1 for this

Jimmy Rufo

Zendesk Luminary

2023年8月22日

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

2023年10月03日

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?

Tony

Zendesk Customer Care

2023年10月04日

Hi there,

I believe that closed or archived tickets should not be updated if you change the field.

Best,

-2

Marcus Vickers

2023年12月28日

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.