Bulk Edit Ticket Requester
Requesters/End-Users leave organizations all the time. If someone has many tickets open, it's time consuming to go through each one and change each one manually.
The standard Bulk-Edit dialog should be updated to include requester in the list of fields.
It's been quoted as a "security issue" before, so perhaps it should be Admin only if that's such a concern.
The API is not an easy solution for Agents who are responsible for managing their Organization's tickets.
-
Official comment
Hey everyone, Thank you all so much for taking the time to share your feedback with us in regards to bulk editing the ticket requester. Our team would like to investigate this feature request in the future and find the best way to address this product limitation. Currently, we are focusing on composer stability so we won't be able to prioritize this to our roadmap for at least the next 6 months. In the meantime, please keep sharing your use-cases with us as this will help us to prioritize this functionality in our future roadmap planning.
-
+1
It it really time-consuming
-
+1
Would be helpful for hundreds of tickets that need the requester reassigned if/when there's turnover with our client (happens several times a year).
-
+1
-
Just to add yet another voice to this debate....we desperately need this too...
-
Today I literally spent 3 hours updating 300 tickets manually because there is no other option to this issue. The value add of Zendesk just went to negative today. The ROI of this function is a lose - lose scenario.
-
+1
Can we get some official response on this please? This takes far too long when we're trying to add one of our existing email addresses as a support address and first have to to change requester for any tickets previously sent from that address.
-
This feature is definitely needed. But, Bulk ticket edit feature already exists, so it's not clear why Requester field is not included in the bulk ticket edit feature. I wouldn't even call it a new feature, it's completing an existing feature.
-
+1
Yes please!
How is this a security concern? The details of the change will be logged.
As the OP said, users leave organisations all the time. Just spent an hour manually updating requester for this very reason. -
The lack of being able to bulk edit requestor has us looking for an alternative to zendesk honestly.
When we receive a large quantity of automated tickets for which there doesn't exist an integration for it can take hours to change each requestor individually so issues can be tracked and recorded in an accountable fashion.
Are there any plans to introduce a workflow for this?
-
@Nicole, I know that your question was directed at Jim, but just to pile on here, we would literally use this feature multiple times every day. It is our number one functionality issue with Zendesk and we get asked about it every time that we train a new agent in for the reason that Casey mentioned above.
-
Another vote for this feature. Our team regularly receives bulk requests that are recategorized as spam, and we have to manually update the requester one ticket at a time, which is extremely time conusming.
-
Hi there! +1
We work in healthcare-related software and this comes up quite often (several times a week/month). Often times users will leave an organization and ask that we add CC's to all of their tickets (status<solved) and/or change the requester to an employee who is staying with the organization so they can take over. This is hugely time-consuming and would save us a lot of time. It seems like the underlying functionality is there already with the bulk update option and there appears to be quite a bit of interest. Is there any update on a feature for this? You'd be our hero! -
Please. Even if it is only for admins. We really need this. especially during Covid, when we are terming whole departments, or several departments at once.
And now that we are rehiring we need this as well, to return users in Bulk, and send their managers their credentials.
-
We also need this. When requesters quit their job in their organizations, i'd like to move his/her tickets ("requester" on those tickets) to another person in that organization. I could merge the user thus moving all tickets, but that also moves one user's details into another, which is not what I want. I also actually don't want to delete the end user, as old archived tickets should stay on that old user, so we can see who managed that old ticket.
Just add requester field to the Bulk edit ticket view, thanks :-)
-
Hey everyone, Thank you all so much for taking the time to share your feedback with us in regards to bulk editing the ticket requester. Our team would like to investigate this feature request in the future and find the best way to address this product limitation. Currently, we are focusing on composer stability so we won't be able to prioritize this to our roadmap for at least the next 6 months. In the meantime, please keep sharing your use-cases with us as this will help us to prioritize this functionality in our future roadmap planning.
-
Still an issue +1 for this feature. The only workaround I have is to leave internal notes to tell the techs to update the requester as they work them instead of me updating one by one manually. 2016 is when this was first raised with several comments throughout the years. Could this be pushed up in priority?
-
Dropping by to add that we would also like bulk edit requester functionality (and have change requester available as automation and trigger options).
Use case - context: Zendesk is used to support stores
- Store submits refund request for customer
- Ticket is assigned to private group
- Finance team action and solve
- After 15 days, automation changes requester to private group so store can no longer view attachments (containing customer bank account details)
It is very tedious to manually change the requested on each ticket
-
At times, we find that there is an incorrect email address in the system - someone may have cc'd an "agent" but misspelled the email, which has created a new account in our system. We want to remove that incorrect email, but we then have to go to each ticket where the incorrect email had been used, such as on proactive tickets created afterwards, and change the requester one-by-one. It would be really helpful to be able to have requester on the bulk edit feature so that we only have to do so once.
-
If you're updating the requester on all the leaver's tickets to the same person, I think the 'Merge into another user' feature on the User page will achieve the same thing?
-
We would like to be able to do this as well. I know that the "best practices" recommends "only" suspending the account. In our case, however, we need an actual working user as the requester in order to get a response to our (e.g., help desk staff) requests for more information, updates, and so on. For whatever reason, our users are much more likely to respond to such a ticket update if they are the "requester of record" than if they are "only" CCd.
-
Hi Jim -
How frequently does this come up for you?
-
@Nicole - I would use this a few-to-several times a year.
-
thanks for that additional detail, Jim!
-
Thanks, Clark. Can you tell us more about why you receive large numbers of automated tickets? That's not a use-case I've come across before.
-
There are a number of tools, such as monitoring platforms, that Zendesk does not currently integrate with. In order to utilize these tools alongside Zendesk, we leverage ticket creation via email. Since the email is not coming from a known, human Zendesk user, that means that we need to change the requester to the appropriate user to allow for ticket tracking and general reporting.
Ultimately, we're changing the requester on tickets on average a couple dozen times per day, but in the not uncommon scenario that there is some sort of large scale monitoring event, we could have to do it across many dozens of tickets.
-
Thanks for taking the time to share that additional detail, Clark!
-
No problem, Nicole.
As mentioned, this is a continual pain point for us. Is there any likelihood that this feature will actually be implemented in the near future?
-
Hi Clark -
I'll have to check in with the product team to see if they have a solution for this problem in the works currently.
-
Great. Thanks for the update, Nicole.
Please sign in to leave a comment.
44 Comments