William Bray

I second this request.  We frequently (daily) have users try to chat with "helpdesk", which results in a suspended Zendesk ticket saying "Sally is trying to reach you in Microsoft Teams."  But since those alerts come from a generic Microsoft address, we can't automatically make them a ticket on behalf of the requester since the requester's email address isn't provided.  

The process described by John would be ideal.  I'm looking into ways to accomplish this via Azure and the Zendesk API, but would love for others to chime in with workarounds as well.

Having a bit of a hard-to-explain issue here.  We have about 115 agents spread across 30 groups.  Often those agents are requesters to tickets in other groups of which they are not members.  Two things are happening:

1. Those agent-requesters can't see the group or assignee of the tickets they request when the ticket is in a group they don't belong to.  We don't want them to be able to assign tickets to other groups (so they must go through the proper email channels), so we disabled the "Agents can assign to any group" option in their roles.  But we DO want them to be able to see who their ticket is assigned to, even if it's just a group name.

2. A bigger issue is that those agent-requesters often "Take" their tickets back to themselves and their own group in what I call "stealing the ticket."  This results in the intended group/agents no longer see those tickets, which means lower ticket count, and not being able to refer back to them later.  

So aside from procedural training, I'm looking for some advice/feedback on how best to address these 2 issues:

1. Allow agent-requesters to see what group their tickets are assigned to

2. Prevent agent-requesters from reassigning tickets from other groups back to themselves and/or their group.

I'd be happy to provide more specific examples if need, but I'm at a loss on how to approach the issues.  

I'd like this feature as well.  We see a couple of use cases in our org.  

1. Trigger to tag tickets that have attachments.  This could be used in views, notifications, etc.

2. Trigger an HTTP target to save attachments.  Example:  ticket is received w/ attachment.  Trigger sends HTTP request to an external logic app to retrieve attachment to save in a central file storage.

Perhaps there's a better way to do all this, but opening up the "has attachments" condition in triggers/automations would allow a lot of flexibility in how we handle ticket attachments.