[Closed for comments] Add or Edit Tags on Closed tickets
I realize the ITIL importance of making closed tickets un-modifyable, as a system of record. But, as a part of post analysis and reporting on hundreds of past closed tickets, mining for patterns of support issues, etc., I would like to be able to add and edit the tags on long closed tickets. For example, if I have an epiphany and want to do something in my Zendesk to help me with something like, "Wow, we sure seem to have been fielding a bunch of upgrade issues with our installed customers over the past 3 months. I think I'll go try to tally those tickets into some kind of category..." ...just as an example. It seems that post tagging might do the trick.
Any thoughts / opinions?
David.
-
Any update on when this feature will be implemented? Will it only affect tags, or will I have access to fix custom fields as well?
-
In addition to this, admins should be able to restrict/limit/control tag creation such that new tags can't be created by agents etc. We have so many version of the same tag with mispellings etc. that not only can we not remove b/c of closed tickets but the list or erroneous tags continues to grow.
-
+1 on this. Not only for tags but other metadata such as ticket type. If someone improperly categorizes a ticket, then we have no way to correct this.
-
Adding my +1 to this. It puts a damper on my reporting if I can't go back and add tags.
-
The first request was in 2009, the "Official Comment" was from about 6 months ago? Is this in the works or should I give up on it?
-
Well, I can't speak for the giving up part @Shane, but PMs that have come and gone from Zendesk have replied to this thread in the past, before the 'Official comment' feature was implemented.
It'd be super cool to get an update on the official comment though :)
This limitation regularly and consistently causes problems that impact our reporting, growth and process changes.
-
If a feedback item is marked as Planned. Please put an expected day, month, year, decade, anything to set some sort of expectation. This issue has been open for a decade this coming December.
-
+1
I am taking over admin duties for our Zendesk instance for purposes of integrating with our BI product and cleanup, but now any improvements I make to data structure cannot be applied to old tickets. My alternative is adding complicated logic to our ETL process to differentially handle tickets based on whether they were Solved before or after a given change was implemented, which I would very much like to avoid.
I'm still very unclear on why Closed tickets can't be modified; it seems like a resource-optimization issue rather than being a user-centric design choice.
-
Hi all -
I'm working on getting an official update for you. As Dan mentioned above, we have some new Product Managers on the team and I need to determine who is taking over issues related to this. I've removed the "planned" tag for the moment, as I don't know which PM put that label here or when. As a rule, we do not share specific dates for ETAs in the community, as mentioned in the Product Feedback Community Guidelines.
-
Hi Zendesk Support,
Not sure if this example was already brought up as a possible use-case, but I've recently discovered that a newly enabled field was improperly set with a default value (when the default should have been null) and we didn't catch this for a few of weeks. We have a heavy influx of tickets so a couple hundred made it to "Closed" status with an incorrect value populated before the issue was remedied. I would love to go back to those closed tickets and simply update that field to "null" so our reporting is correct but the limitation of "No editing on Closed tickets" is a problem. Please consider this example, if you haven't already, in your discussions to allow for tickets in Closed status to be edited. Thanks!
-
Thanks for sharing that use case, Damon!
-
We are a new user of the tool and as we implement and understand how we will best use the system, we have easily found some ways to improve during the first month. As a result, our analytics are a mess because we updated some options in the drop down after learning. This seems like a basic option to be able to enhance your system and backdate improvements for more meaningful analytics.
Is this still being offered as a potential enhancement? There should be a way to accomplish this as an admin. We are looking to update custom strings.
-
I'd like to up this topic. It would be really handy to be able to edit closed projects. At least add / edit tags in our use case.
Thanks
-
We are experiencing the same issues with tickets classification.
The auto-tagging system appears to cause more trouble than good, so it was decided to disable it.
Though we have a bunch of not related tags in our system now (including those misspelled by the staff), those appear in the auto-complete box when entering tags for new tickets and the support staff is making more and more mistakes.
We need a way to replace tags for Closed tickets, as well as a way to actually manage those already recorded in the system (an ability to mass replace one tag with another, allowing to correct the situation caused by the auto-tagging system).
Since you are not sharing ETAs with the community according to your rules, I have gone ahead and created a support ticket hoping to get the information we need.
I believe that the best way for the community to raise the priority of this case is to not only add a comment on this thread but to create a support case also.
Thank you.
-
+1
We seriously need to be able to modify tags after a ticket is closed. Otherwise, trackings and data provided are inaccurate. Please seriously consider this function. I find it ridiculous to not be able to modify or change the tags. Thanks!
-
Hi Dmitry -
This is something that the Product team is currently looking into. However, there is not currently a way to edit tags on closed tickets, nor are there currently workarounds to accomplish this functionality. Closed tickets, as they exist today, are simply un-editable.
That being said, we're very much aware of the request. It's technically a very difficult thing to implement, as it requires changing one of the fundamental ways that the product works. This is part of why it has taken a long time for the team to work on.
For other users: posting in the Product Feedback forum is currently the best way to voice your feedback. The Customer Advocates who respond to those tickets have no more insight or ability to share ETAs than we do here in the Community. Our internal process is to direct all feedback here, so submitting it in a ticket will likely result in your being redirected back to the Community anyway. We are looking at better ways to capture and respond to feedback from users, but this is the process we have for the time being.
Thank you all for your comments. We'll share updates here when we have them.
-
Nicole:
Editing the fields IMO is far more important than tagging, and I've stated such earlier on this thread.
I do understand your dilemma in the fundamental change this request make in the system. IMO if you could add a new state after SOLVED before fully CLOSED that was essentially "CLOSED_EDITS_FROM_ADMIN_ONLY" and allowed tickets to remain in that state for at least 6 months or possibly 1 whole year, that would be a good transition time that probably covers 95% of the needs for those of us asking about this. My desire, and many others I have read along the way has always been to be able to correct field-entry mistakes that our agents make when marking tickets as resolved. Since those mistakes today are not correctable, it makes much of the data we try to collect skewed towards ineffectiveness. So allowing an ability to tweak certain fields during a transition state seems like it would be a good compromise that would be beneficial to admins, yet still allow Zendesk to keep the historical archiving working the same way it does today.
-
Tags and field editing are very important, but also attributes like Ticket Organization for example are really important too.
Because there's no Merge Organizations feature (and there isn't going to be one, according to the last official update) we need to be able to move a requester's tickets to a new organization if needed, so we don't fragment ticket history when one of our customers buys another, or when we need to correct a sync issue and remove duplicate accounts.
IMO in order to successfully scale with the needs of the different of Zendesk users, all ticket properties should be editable by an administrator or other role-specific permission once Closed.
-
I 100% agree, administrators need the power to edit 'closed' tickets. it's our data, and we need to be able to modify it appropriately to allow for meaningful analytics (that we pay extra for).
-
+1
Hundreds of tickets... Sitting there. All without tags. They are just useless. I can’t understand why Zendesk insists on this one. It has been almost 10! years since this request was made.
-
+1. Zendesk, open your ears and listen to all these people. There are more than enough examples in this thread of reasonable use cases for the requested feature.
I too have hit this roadblock. I can't make the reports I need without backfilling missing data. I've made some fields required, which will help in the future, but that won't help past tickets. Also, what if the agent wrongly categorized a ticket and I don't find out until it's closed? I can't fix it.
-
+1
Reporting requirements from a channel partner changed a year into the project, we now need to merge historical reporting with go-forward reporting in excel for any useful analytics (given that we have to host retroactive field modifications outside of ZenDesk).
This is a material enough issue that I will likely review other integration tools for my support team. It's inconceivable that a community ask this vocal wouldn't be inserted into the product roadmap some time in the last ten years - regardless of size.
-
I too, am looking for an alternative software at the moment. At least, now I'll make sure that this is already implemented in the software.
-
Hi all -
The product team has informed us that they're going to pursue exploration of this problem and potential solutions to it in Q3 of this year. The team is very highly aware of this request and need for this functionality and we will be back with any follow-up questions related to it as the investigation process ramps up.
-
👏
-
The fact that this is impossible almost breaks the software for us - as we evolve and edit fields and look to integrate with other platforms, we need the ability to revise historical data to line up with the latest structure.
-
This seems to have been a request for almost 10 years. Which implies that Zendesk is not going to change their minds about it. Might be nice if you could say more about why. It's not like other systems don't allow annotation of closed tickets.
My use case is probably similar to that of a lot of other customers: we added a Product Area property to allow us to better mine support data for areas that would most benefit from additional development or documentation investment. We took a first stab that those categories, and added an Other for the rest. Now we would like to go back and split out Other into additional categories as well as categorizing the historical tickets that were added before we had Product Area. Having to extract ticket history and then backfill that data in an external system, and report on it in an external system, seems unreasonable.
-
Hi Paul -
As I said in my previous comment, the Product team is looking into this. It's taken a while for a number of reasons, including that it's a technically difficult thing to do within our platform, meaning that prioritizing it mean de-prioritizing lots of other things that we deemed more important to a greater number of users.
We appreciate your feedback, and will continue to update this thread when we have news.
-
Hi Nicole,
Could you post your previous response that this is being looked at at the Official Comment for this thread? That way it'll be visible for anyone arriving at the topic.
Currently, it's only found if people read through all the comments, which are getting to be quite long for this topic.
-
It took 10 years to Product team to look into this. I’m optimistic that we’ll get this feature sometime between 2025-2030.
Post ist für Kommentare geschlossen.
260 Kommentare