Craig Wilding

Greetings.  I think this may help if your business case matches ours.

We need to be able to "bounce" or forward a ticket onto a 3rd party who isn't a Zendesk user.  We want the 3rd-party group to be able to comment on the ticket and have their response visible to the original requester (our employee) and the Support Agent.  

Facing solutions fraught with unnecessary complexities, we instead did the following: 

1. Created a Macro that added a unique tag
2. Created an HTTP Target, dogfooding the Zendesk Ticket API
3. Created a Trigger to invoke the Target based on the tag
4. Added a 2nd tag to prevent the trigger from firing on next updates

Here's how:

1. We created a "Bounce to Group XYZ" Macro, which adds a tag specific to the 3rd-party - i.e. "group_xyz."  The tag is added when a Support Agent wishes to manually bounce the ticket to our XYZ folks, but still wants the requester to be part of the conversation.
2. Created an HTTP Target (Extensions >> Targets >> Add Target >> HTTP) with the PUT verb and JSON content type.  The URL is the Ticket API endpoint with a placeholder tag for the TicketID: https://yourdomain.zendesk.com/api/v2/tickets/{{ticket.id}}.json.
3. Created a "Route Request to XYZ" Trigger, which fires upon both a ticket update and when the "group_xyz" tag is present.  The trigger immediately adds an extra tag to flag that the request was dispatched.  Subsequent ticket updates don't fire the trigger because it checks for the absence of the dispatch flag.
4. The Trigger payload (JSON body) includes the additional CC user(s) and a comment for the new CC user(s) to see: {"ticket": {"additional_collaborators": [ { "name": "Group XYZ", "email": "group@xyz.com" } ], "comment": { "body": "Ticket #{{ticket.id}} assigned to [Group XYZ] from [{{ticket.requester.name}}] by [{{ticket.assignee.name}}]." }}}

This is a simple use case for using the Zendesk API, which is very robust.  Hopefully we'll be able to continue using it this way because it's an ideal workaround.

Best,

Craig.