Tiggers/Automation-based Notifications: Workaround for posting comment in ticket
Problem: When you use a trigger or automation to fire a notification, it is only possible to see the notification in Events - the notification is not appended as a comment to the ticket. This creates agent confusion, since they cannot readily see what notification the requester received in the ticket thread.
Workaround solution:
If you set the ticket to close upon firing a notification with a trigger or automation, when the requester responds to the ticket, the original notification sent by trigger is appended to the follow-up ticket as an internal note. From there, the ticket can resume in a back-and-forth thread as normal. so, we have every auto-sent notification close the ticket when it sends, so that agents can see what was sent to the requester when they respond.
Here's an example of what I mean (image censored for business confidentiality purposes) -
- We have a trigger set up to auto-fire a text notification to certain voicemail tickets. Thie trigger sets the ticket to close upon firing the notification.
- This notification does not appear as a comment on the original, closed ticket that it is sent upon.
- When the requester responds, this is the new ticket that enters the queue, that the agent can then work from with the context of the auto-sent notification as an internal note. while this use-case is text, it also works for email:
-
Official comment
This is an amazing tip! I'll be sure to share this with others in our next Weekly Digest!
-
Would it not be better to keep this all on the same ticket? You should be able to use a http target to add a private note of the notification sent. Would that help?
-
Andrew J - I agree that it's ideal to keep it all on the same ticket, and this is a workaround for that specific limitation, choosing to instead give agents context and creating a new follow-up thread (associated with the original ticket) that contains the notification that was sent. I am not very familiar myself with using http targets and do not know if that would create a similar workaround while keeping it on the same ticket! If you try that, please report back!
-
Actually - it's easier with a URL target.
Admin (gear) > Extensions > Add Target > URL Target. Then use details as in image - substituting your URL and login.
Full URL is https://yourURL.zendesk.com/api/v2/tickets/{{ticket.id}}.json?ticket[comment][public]=false
Once done, just add an action to your automation (whatever is doing the message that you are needing to see).
> Notify target , [your target as above], and the message you want your agents to see. something like 'Automatic message sent to user: "This is the message content" '
You should no longer need to close the ticket to see the notification that was sent.
-
^^ That's the method we use. Works a treat :)
-
This sounds way better than closing a ticket.
However, I'm not getting it work. What do I have to set as attribute to get a Private (internal) comment?
-
If you set the URL as https://yourdomain.zendesk.com/api/v2/tickets/{{ticket.id}}.json?ticket[comment][public]=false+ and the Attribute Name as ticket[comment][body] Then this will setup the extension correctly.
Within the trigger, you would then create a Notify Target action pointing at your new extension and enter the message you wish to add.
This will then add the message as a private comment.
-
It's working! Thanks a lot!
-
Excellent, not a problem! :)
-
Hi Phil,
I tried your solution using the URL target to update tickets in the Dev System and that's exactly the solution I've been searching for. Did you ever had problems with this solution concerning a race condition or something else?
Many thanks in advance and regards
Michael
-
So first Montana great write-up, a shame you had to do it in the first place.
Rather than implementing the features like triggers for change/update subject or Add Private comment that so many Zendesk admins have been requesting for years now, it seems like Zendesk is almost encouraging the use of a method that will artificially impact ticket metrics if this exact case is not accounted for in reporting. A method that if you have a password change policy enforced by an SSO or IDP will break. This will also falsely attribute comments to an Agent unless you pony up for an Agent license to use as a service account for this use case.
This is exactly why my Agents joke about Zendesk feature requests being the "Wishing Well of Lost Pennies"
Please sign in to leave a comment.
11 Comments