
One of the most important considerations when building triggers (or other business rules) is to be as specific as possible when creating conditions. You want to apply the trigger only to relevant tickets. A good example of this, and a common mistake, is forgetting to set the trigger's scope using the Ticket is condition. This condition has two values: Created and Updated.
The use of this one condition can make a significant difference in how many tickets are processed each time triggers are run.
For example, if you're creating a trigger that routes tickets based on some criteria as they are received in your Zendesk, you want to include the Ticket is... Created condition to the trigger. Doing so ensures that this trigger only applies to tickets when they are first created and not applied to those same tickets when they are later updated. Tickets are only created once of course.
Here's an example of a trigger that uses the Ticket is...Created condition and assigns newly created tickets containing specific tags to the Level 2 support group.
This trigger runs once for every newly created ticket that contains either of those tags.
What would happen if we didn't set the Ticket is...Created condition? Each time a ticket containing either of those tags is created or updated, it would be assigned to the Level 2 Support group (because all of your triggers run each time a ticket is created or updated and there are no conditions preventing the group assignment from reoccurring). Of course, that's what we wanted initially but what if we had subsequently assigned the ticket to different group? The ticket may be reassigned to the Level 2 Support group each time it is updated.
If you do want to apply actions to tickets, based on some criteria, each time they are updated you use the Ticket is... Updated condition.
The most common example of when to use this condition is when you want to send notifications to the requester. To see an example of this, take a look at one of the default notification triggers in your Zendesk account: the Notify requester of comment update trigger, for example. You want those actions to occur each time a new public comment is added.
The default behavior of a trigger that contains the Ticket is...Updated condition is that the trigger's actions will be repeated each time the ticket is updated as long as the trigger's conditions remain true.
This means that you can also use the Ticket is...Updated condition and apply the trigger's actions only once to a ticket. For example, perhaps we wanted to make our bank customer tickets high priority. We only want that to happen once. To do that, in addition to the Ticket is...Updated condition we also add a condition that checks to see if the ticket's priority has already been set to high. In other words, if the ticket doesn't meet the criteria defined by the conditions, then the trigger is not applied to the ticket.
In this trigger, we're setting the priority of any tickets for bank customers (we know they're bank customers because of the tags we've added) to high priority the first time the ticket is updated. But first, we check to see if the ticket's priority is already set to high, which would indicate that the trigger has already run on the ticket. If it has, the ticket is not updated.
14 Comments
Is there any way to have a trigger set the ticket priority if the ticket name contains certain words? For example, if a user creates a ticket with the word "urgent" in the name, then the ticket would be created with Urgent set as the priority. I know this can be one with tags, but we're looking for the same functionality with the name field. Thanks.
Hi Russel!
You can accomplish this using the Ticket: Comment text condition in your trigger:
This condition will check for the key words you specify in both the subject and description of the ticket - there's no way to specify just one or the other.
The only thing to remember here is that this will cause the trigger to fire on all tickets that contain that key word, so you might end up with some tickets marked as urgent, even though they shouldn't be.
Hope that helps!
Jessie,
Yes, that is very helpful. Thank you!
Hi There,
If I understood correctly the Comment text condition checks both the subject and the description of a ticket.
But there is also the subject text condition. Does this also check the description of a ticket?
If this is the case I miss the logic behind having a comment text condition that checks also the subject of a ticket.
Hope you can clarify!
Thank you.
Hey Edoardo!
The Comment Text condition can check both the subject and description of a ticket. It will only do so when being used with Ticket Is Created. If you use Ticket Is Updated, then the Comment Text condition will only apply to the body.
Subject Text will only ever check the Subject and will not check the Description of a ticket. The Subject Text condition can be used with Ticket Is Updated whereas Comment Text would not check the Subject in this situation.
For a breakdown of each condition in Triggers I recommend Creating and managing triggers for ticket updates and notifications.
For a breakdown of each condition in Automations I recommend Streamlining workflow with time-based events and automations.
You may also reference When creating a view or automation, does the condition Ticket: description... only apply to the first comment in the ticket?
'Comment is present' is ambiguous - does that mean a new comment is present or just there has ever been a comment present?
Hi Claire!
It means that a new comment is present on the ticket update that is causing the trigger to fire.
To put it another way, let's say you've created a trigger with Comment is present as a condition. If you submit a ticket update with a new comment, the trigger will fire. If you submit an update with no new comment (just other attributes updated), the trigger will not fire.
Let us know if you need more help!
I want to make a trigger that adds a tag to an incident ticket that's updated without a comment i.e. comment is NOT present because it's solved through a problem ticket. How can I go about making that without the 'comment is not present' condition?
Hi Khadeeja,
I'm afraid there's no condition available for comment > is not > present at this time. The closest you would be able to get is the following trigger:
However, this trigger would fire each time you updated the incident ticket status to solved regardless of whether or not the comment was added.
Are you attempting to add this tag for tracking purposes or what exactly is the intent of this tag?
Let me know!
This is what I have so far. What I want to do is add a tag to incident tickets that went from "on-hold" to "solved" without any public comment.
Hey Khadeeja,
I think the trigger you have set up is definitely the closest workaround you'll get to this. Since there's no condition for comment>Is not>Present you won't be able to do much else, unfortunately.
Let us know if you have any other questions!
Is there a way to set a trigger to automatically pull tickets into a view instead of going into the general inbox and the view? Thank you!
Hi Greg -
Views operate more like search filters than they do folders, meaning that if a particular ticket meets the criteria for multiple views, it will show up in both/all of them.
So if you want your tickets only to show up in a specific view and not your general inbox view, you should change the conditions on your general one to exclude the tickets you only want to see in the other view.
It would be great if we could have a trigger for 'Ticket...is...Deleted'.
(also see a similar request here: https://support.zendesk.com/hc/en-us/community/posts/360043939473-Trigger-for-when-a-ticket-is-deleted)
Please sign in to leave a comment.