Question
I want to update tickets using a trigger or automation. The ticket attributes I want to update are not accessible using triggers or automations. I can make the update successfully using your API. Can I have the trigger or automation notify a target that updates the ticket via your API?
Answer
No, this workflow is not recommended or supported as errors are likely to occur when the ticket is being updated by triggers and the API simultaneously. When this happens, it is called a race condition. Triggers are used to explain this issue below, but the same principles apply to automations.
Every time a ticket is created or updated, all of your triggers run in a cycle against that ticket. A trigger will fire and update the ticket if it's conditions are met during the cycle. A cycle is the entire process of a ticket being checked against all your triggers.
When a trigger updates a ticket using our API, the update occurs at some indeterminate point in the cycle. Results can vary based on when the ticket update occurs in the cycle. The ticket update can affect whether other triggers fire.
16 Comments
I agree with the race condition. We have used this to update the time spent in the comments section after entering it in the time tracking app. The target was setup in the Trigger. There are times that it will conflict with other triggers too and there are times that there are errors in the output of the date and hours in the comments section. Nevertheless, the target has worked for us most of the time. It is just not guaranteed to work perfectly at all times.
If you do not support this workflow, why is it being offered as a solution to automatically adding end-user CC to tickets?
The only available, and complicated, solution is one you do not support, and this feature request has STILL not been addressed in well over 7 years:
https://support.zendesk.com/hc/en-us/community/posts/203422496-Add-end-user-as-CC-via-Trigger-or-Automation
Hey Tom!
Community Tips & Tricks like the one you're referencing are customer-submitted work-arounds or customizations. It's not unusual for these to not be officially supported because we cannot guarantee that they won't break when we make changes to the platform, or that core system functionality won't create a conflict that will cause the workaround to fail, as in the case outlined above.
Although we don't recommend or support this workflow, some members of our Community have used it successfully. We leave the tip posted because people have found it useful; it's important, though, to proceed with caution and understand that your mileage may vary.
In the interest of clarity, we're going to add some additional information to that tip to avoid any further confusion.
I would still love to see Tvis feature.
It would let me Update tickets from other platforms like Slack or Teams.
This feature would really help a lot
The responses from Zendesk in initial post:
'If a workflow is not possible using our native functionality, it's probably for a reason.'
and
'Consider re-evaluating what it is you want to accomplish. In most situations, you'll discover a simpler approach to solving a problem.'
Isn't really adequate, and feels a bit patronizing, to be honest. In our experience, the 'reason' is just that it's not been done on Zendesk's side, in some cases in spite of overwhelming and longstanding feedback from users requesting it, such as the request Tom linked to above. The 'simplest' way to solve the problem would be to just be able to select a given ticket property from a drop down in the trigger setup.
As a user of the self-target API workflow, I'd much prefer not having to use them. What would be better would be if Zendesk added more ticket properties as actions in triggers, or at least aimed for parity between things we can evaluate and things we could act on.There's a lot of feature requests that demonstrate a longstanding desire from users for things are often accomplished with these workflows.
Example 1. We would like to automatically change the recipient email on a ticket, so that our outbound replies come from a certain address if certain conditions are met, such as a VIP customer who contacts the regular support email. They should have their reply sent from a special VIP@ email, instead of the default one for the brand. Ticket Recipient cannot be set as an action in triggers, though it can be used as a condition in the trigger ( 'Ticket received at' ). If we can evaluate it as a condition, why can we not act on it?
1a. We'd also like to be able to CC their account manager or another end user when these users create tickets! ( a feature request that's 7 years old, 327 comments and 312 upvotes!)
Example 2. - Another common use case is field scrubbing when customers create followup tickets. Text, numeric and date fields can't be cleared by a trigger when a follow up ticket is created. We don't want or need the duplication of data into the new ticket, the issue might not be related. By prefilling a value, it bypasses any restrictions around required fields.
Customers often create a follow up for an old issue just because it's easier to reply to an email they received than try to go to the HC and fill out a new form.
There's no doubt this workflow of using a trigger to self update Zendesk via the API isn't a great one. Unless Zendesk implements the ability to triggers and automations to utilize *all* ticket properties as a condition and as an action, it's going to be a necessary evil that continues to irritate your admins, agents and users (and probably your support team). At the very least, if all the properties can't be done, they should be able to have parity between being a condition to evaluate and an actionable property.
Hey Dan! Thank you so much for the really detailed use case you've provided here!
I hate to ask you to post in a second place, but I'd love to see you copy/paste your comment to the Product Feedback post about this as well. Our Product Managers can't be everywhere in the Community, but they do see all the comments in Product Feedback (even though they can't always respond). Details like what you've outlined here are what they need most, to understand the problem customers are trying to solve. If you don't mind the extra clicks, your feedback will be really helpful in that thread!
Done. Thanks Jessie!
No problem! Thanks for being a good sport. :)
So annoying! Is the risk lessened on automations than triggers since automations are only evaluated hourly and by then it ought to be able to correctly check if a tag exists before running again?
Hey Rob,
I'm sorry you're finding this troublesome. Unfortunately, automations aren't necessarily any better than triggers. You still have the potential for that activity cycle to create a race condition and create inconsistent results or errors.
I have got this workaround from a Zendesk supporter - how can I make this workaround without using targets and triggers to update tickets. ??
Dan Kondzela(Zendesk Support) (#3207219)
Hey, Helle! Thank you for reaching out to Zendesk Support. I appreciate you taking the time to write in about your problems.
I believe the quickest workaround here would be to create a custom Ticket Field that can mirror the organization a ticket is attached to and make it visible to end-users.
Hi Helle!
Can you be more specific about what you're trying to do?
Hey Helle and Jessie!
I feel I better step in here and offer some clarity. When I made that suggestion I was misunderstanding your end-goal. I apologize for not addressing this more clearly in the ticket response, but I am afraid I must defer to my colleague's statement on the matter.
Unfortunately there is no native way to achieve what you are looking to do. It may be possible to modify the code or create a custom JS script that permits the search to look through multiple organizations. However this would be outside the realm of what we provide support for.
I thought the ability to filter tickets by Organization in the end-user's My Activities page would provide the functionality you are looking for. I can see that I was mistaken in this assumption, my apologies for that! Feel free to reply or create a new ticket for greater clarification.
Seems to me like it should be OK to try these practices (as there is no safe, built in functionality), and if there are issues, just cancel the trigger or automation.
Hi David,
You are correct and it's OK to try using a trigger and target to update your ticket. In some cases it will work and others it will not. We just set the expectation that if any issues should occur it's most likely due to this unsupported workflow. As you stated you can just disable the trigger/automation if any issues should come up.
Cheers!
Hi All,
I am fairly new to Zendesk, and i am vastly disappointed in seeing small functions not implemented in Zendesk, especially for the customers. Most of the applications we looked at had basic functionality that Zendesk does not provide and has not over the years by what i am reading. Simple things like, the order the messages are laid out in the ticket, extra fields (custom), sorting, exporting, reporting, etc.
We resort to implement whatever we can to make our customers happy since we rely on the SLA from our customers contract. Basically, we are forced to use like the target triggers to resolve something Zendesk should be providing in the first place.
For me, the target triggers work wonderfully, i use it to capture the 1st SLA - Customer Acknowledgement in the public reply of the ticket. Most of our customers are Airlines, and you could imagine the million emails received by them. This is where they go to ensure that an email was sent acknowledging their issue.
I believe, criticism on what we are doing does not help us find a solution to the inadequacy functions of Zendesk. We understand there are limitations, but then push for a better Zendesk Customer Experience!
Thanks,
Yami
Please sign in to leave a comment.