Feedback: Increase Bulk Edit Limitation
Feature Request Summary:
Zendesk Support should increase the bulk edit limitation beyond 100, or give the option to increase the limitation in the Admin Center.
Description/Use Cases:
We have multiple, frequent use cases in which we need to edit way beyond 100 tickets at a time. Some examples are:
- After a system outage, we’ll often need to reply to a couple thousand tickets to let users know the system is back up.
- After a new content release, we’ll often need to reply to a few hundred tickets to let users know how to work around a bug or the like introduced in the release.
- After a spam attack, we need to delete upwards of tens of thousands of tickets.
We do utilize problems/incidents, but they have the same bottleneck; we can only link 100 incidents at a time.
Business impact of limitation or missing feature:
We have built a custom app which allows us to go beyond the 100 bulk edit limitation, but we now have to maintain that app. It would save us a lot of time on the part of our agents, and effort/cost on the part of our developer, if we were simply able to edit more than 100 tickets at once in the out-of-the-box product.
-
The current UI limitation of 100 tickets seems to be a reflection of the limitation of the bulk/batch API operation which can only update 100 tickets at a time (per job). However I agree, I think it would be a powerful and much appreciated enhancement for the UI to permit the user to request updating more than 100 tickets at a time -- or even all tickets in the view -- and then handle the creation of multiple jobs to update all the tickets requested. The current experience of only being able to check 3 1/3 pages of a view is very unnatural.
Regarding the limit on async jobs which would be reached as the number of unprocessed tickets approaches ~3000, the UI could give feedback about failed update_many updates, much like how it does already when individual tickets fail to update (within a single job of 100). Or even better, the UI could coordinate creating new jobs as the async job queue has capacity for more jobs, either by querying the job queue or retrying on job failure after delay.
I'm glossing over the tricky issues like batch vs bulk safe_update behavior and what it even means to update tickets in a view of tickets that is constantly changing, but these are issues I'm confident that Zendesk team can find good solutions for.
Por favor, entrar para comentar.
1 Comentários