Alex Chan

We also have a business requirement which would benefit from setting recipient via trigger:

When an agent creates an “outgoing” ticket (first comment public from agent), the recipient needs to be customized according to ticket fields (built-in and custom).  We are also using webhooks as a workaround, however the initial email notification is sent with the default recipient, or the recipient specified by the Select an Address app.  The problem of course is if the agent forgets to use the Select an Address app or does not know the correct recipient to select, for the use case, then the recipient will be incorrect for the initial email notification, even if it is updated via webhook.

Thanks for considering adding this feature.

It's easy for customers to mistake the updated ticket comment as a new agent comment.  Including the date of the comment from the ticket that was merged-closed would make it clearer.

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. 

Adding the rich text editor to merge comments would also be helpful.