Question
I want to update tickets using a trigger or automation. The ticket attributes I want to update are not accessible using business rules. I can make the update successfully using the Support API. Can I have the trigger or automation notify a webhook that updates the ticket through the API?
Answer
No, this workflow is not recommended or supported. When a ticket is updated by business rules and the API simultaneously, errors are likely to occur. When this happens, it is called a race condition.
Every time a ticket is created or updated, all your business rules run in a cycle against that ticket. For instance, triggers fire and update the ticket if their 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 the 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 business rules fire.
For more information about triggers, see the article: About triggers and how they work.
As an alternative, consider using a ZIS Flow to accomplish a similar outcome.
12 Comments
We have to use this method too despite the advice not to, all we want to do is add an internal note to the ticket when an automation has run so that the agent who picks the ticket up is aware of what has gone on in the ticket (eg. a chaser email has automatically been sent to the customer).
This is clearly something many customers want, and need, to do and are being forced to use a risky working around. Is there a reason that this basic functionality can't be added?
The lack of more sophisticated workflows is becoming more and more an achiles heel for Zendesk as the requirements of customer support/experience/operations teams continue to increase in complexity. The basic triggers are great for a traditional service desk but to manage cross-functional business processes you need something with a little more firepower.
This article is sadly inaccurate.
The correct answer is Yes - BUT!
An entire article explaining why you shouldn't do something does not negate the fact that you can. This option is used by many zendesk administrators with caution. It is used as the basis for many support articles even.
And by Brett ;) https://support.zendesk.com/hc/en-us/community/posts/4409515238554-How-to-allow-email-target-responses-to-thread-into-existing-ticket
Zooming out a bit on the trigger topic and on the 2 topics RichL raise about sophisticated workflows and include costs for a 3rd party workflow builder, I can see this being true for some customers (including myself).
The reason for many of us visiting this article about triggers + webhooks is the many limitations in the trigger framwork, both in what actions/conditions are available, in it feature limitations like poor support for webhooks that call back.
I think the trigger framework also scales poorly when you Zendesk grows, and I think it's rather tricky to configure (without errors), compared to many modern "flow builder" or "code" type workflow frameworks.
Searching on the product feedback forum just now, I didn't find a specific request to allow better support for using the trigger framework to do delayed actions for webhooks, or requests for more sophisticated workflows, but many of Zendesk Support product feedback requests are on that topic: triggers to add internal notes, support dynamic placerholders/expressions for update values, changing recipient email addresses, etc.
So I'm confident Zendesk is very much aware of the current workflow limitations, and evaluating how to evolve the trigger framework to the next level, so those of us that us triggers + webhook workarounds can use built-in tools from Zendesk to accomplish our goals instead.
Tip if using API, Zapier or other 3rd party service
If you have developer resources available or are using the Zendesk API or a 3rd party tool like Zapier to complement triggers or automations, I'd definitely recommend you also read the article about safe ticket updates, to increase the stability of your flows when multiple updates within the same timeframe/ticket updates collision might be a possibility: https://developer.zendesk.com/documentation/ticketing/managing-tickets/creating-and-updating-tickets/#protecting-against-ticket-update-collisions
Bobby Koch - they didn't remove it... they just don't recommend that you use it. It is possible and we do use it in our environment. We understand the risks and do extensive testing to ensure that it doesn't mess anything up. We aren't trying anything too sophisticated at this point. If we ultimately have that need, we will likely be looking at an external tool to do that :(
So this functionality existed with extensions/targets, but now is not supported with webhooks? Why are we moving backwards?
What, exactly, is the purpose of webhooks in Zendesk as a supported incorporated feature, if we're told in 2022, that the use of that feature is not supported in any way? I understand internal notes via webhooks not being supported but what is the point of webhooks if *any* updates via the webhook are not supported or recommended?
Hi,
I didn't open this ticket -- I found a nice explanation of use cases here: https://support.zendesk.com/hc/en-us/articles/4408839108378-Creating-webhooks
You can close this.
Agree with Andrew here - for savy admins with complex use-cases, webhooks with triggers is the only solution outside of using an integration tool. The article had to be written for a general audience, as the author is correct in that you can cause race conditions. However, use common sense: if you launch your trigger by adding a tag, remove the tag in the trigger and not the webhook. This is true for any field used for routing or notifications. For most use-cases, either a new ticket is created or fields copied over, but double check that fields you're updating aren't going to be used in further business rules - for example my webhook triggers are usually initiated by a macro that adds a tag.
If ZD is concerned about this process, I'd recommend a feature that allows dynamic vs. static assignment of fields i.e. copy a defined field into a custom field, add a defined list of followers per ticket type.
Hi,
You can automatically add comments to specific tickets with the Proactive Campaigns app. It has a new automation feature, so you can use it to send emails and add internal notes in bulk. The app adds internal notes when tickets enter the list filtered by specific criteria. It's extremely simple to use!
Have to agree with Andrew here: triggers + webhooks = There be dragons, but as a long time Zendesk admin, I have to acknowledge triggers + webhooks is one way to solve business problems that might be hard to solve other ways today.
I'd also caution what is already stated by multiple people: if you take this path, you are on your own if you want support from Zendesk, or if you experience unanticipated behavior.
Tip
Without diving into details, if you do use webhooks + triggers, I'd suggest you try to position the trigger for the webhook at the very end of your trigger run, at the point where you expect all other triggers have had their conditions evaluated (=no longer any chance they will fire), when the trigger run is about to end.
I too want this functionality to update a field with a numeric value when firing an action, whether that be through a macro, trigger or automation.
I guess we'll see what they have in their feedback forum...
Please sign in to leave a comment.