This article describes the different conditions and actions you can use when creating triggers. For information on creating new triggers, see Creating trigger updates for ticket updates and notifications.
Building trigger condition statements
Condition statements consist of conditions, field operators, and condition values (these vary depending on the condition selected). Condition statements are essentially ‘if’ statements that return all tickets that meet the specified criteria.
For condition statements such as Ticket: Status, Ticket: Group, and Ticket: Assignee, the trigger will fire whenever the condition is changed. Changed refers to any update made to the value, even if the value previously did not exist. For example the Ticket: Group trigger condition will fire even if a ticket is created and a group is assigned to it for the first time.
Condition | Description |
---|---|
Ticket: Status |
The ticket status values are: New is the initial status of a newly created ticket (not assigned to an agent). Open means that the ticket has been assigned to an agent. Pending is used to indicate that the requester has been asked for information and the ticket is therefore on hold until that information has been received. On-hold means that the support request is awaiting a resolution from a third party—someone who is not a member of your support staff and does not have an agent account in your Zendesk. This status is optional and must be added to your Zendesk (see Adding on-hold ticket status to your Zendesk). Solved indicates that the customer’s issue has been resolved. Tickets remain solved until they are closed. Closed means that the ticket has been locked and cannot be reopened or updated. When selecting a status, you can use the field operators Less Than and Greater Than to specify a range of tickets based on their status. New is the lowest value, with values increasing until you get to Closed status. For example, a condition statement that returns only New, Open, and Pending tickets looks like this: Status is less than Solved. |
Ticket: Form
(Enterprise plans only) |
Your ticket forms are available as conditions. Select Ticket: Form, then select a specific form.
See Creating ticket forms to support multiple request types. |
Ticket: Type |
The ticket type values are: Question Incident is used to indicate that there is more than one occurrence of the same problem. When this occurs, one ticket is set to Problem and the other tickets that are reporting the same problem are set to Incident and linked to the problem ticket. Problem is a support issue that needs to be resolved. Task is used by the support agents to track various tasks. |
Ticket: Priority |
There are four values for priority: Low, Normal, High, and Urgent. As with status, you can use the field operators to select tickets that span different priority settings. For example, this statement returns all tickets that are not urgent: Priority is less than Urgent |
Ticket: Group |
The group values are:
Additional value for views:
|
Ticket: Assignee |
The assignee values are:
Additional value for views:
|
Ticket: Requester |
The requester values are:
Additional value for views:
|
Ticket: Organization |
The organization values are:
|
Ticket: Tags |
You use this condition to determine if tickets contain a specific tag or tags. You can include or exclude tags in the condition statement by using the operators Contains at least one of the following or Contains none of the following. More than one tag can be added. Press Enter between each tag you add. |
Ticket: Channel | The ticket channel is where and how the ticket was created. The contents of this list will differ depending on the channels you have active, and any integrations you are using.
For more information about common channels in this list, see How are ticket channels defined across Zendesk? For more information about the ticket channels you can configure, see About Zendesk Support channels. |
Ticket: Integration account | This condition checks the integration account that the ticket came from, such as a specific Facebook page, Twitter handle, or other channel integration account, like Google Play. Select one of your configured integration accounts from the drop-down menu. |
Ticket: Update via | This condition indicates from where the ticket was updated and can be any of the same sources as the ticket channel condition (above). |
Ticket: Received at | This condition checks the email address from which the ticket was received and the email address from which the ticket was originally received. These values are often, but not always, the same. The ticket can be received from a Zendesk Support email domain such as sales@mondocam.zendesk.com, or from an external email domain such as support@acmejetengines.com. The external email domain must be set up as described in Forwarding incoming email to Zendesk Support or the condition won't work. |
Ticket: Satisfaction
(Not available on Team plans) |
This condition returns the following customer satisfaction rating values:
|
Ticket: Is | Created or Updated. Created will fire only when a new ticket is created . Updated will fire only when an existing ticket is modified and submitted. For more information, see Triggers: The importance of the 'Ticket is' condition. |
Ticket: Subject text | Using this condition you can check for the presence of single words and strings of words in the subject line of the ticket. This condition is not case sensitive. You can use any of the following operators:
|
Privacy | This condition lets you test if a ticket has public comments or not. You can select either:
|
Ticket: Comment is |
This condition returns the type of comment contained in ticket updates. Public is a comment that everyone can see. Private is a comment that only members of the support staff can see. Present (public or private) is used to indicate if the update contains a new comment. Present, and requester can see the comment is used to indicate that the update contains a comment and that it is visible to the requester. This includes private comments, if the requester has permission to view them. |
Ticket: Comment text |
This condition checks for the presence of single words and strings of words in the body of a new comment when a ticket is updated. For newly-created tickets, the first comment in the ticket is checked. A previous comment in a ticket is never used to evaluate this condition. The following content is also checked under certain circumstances:
This condition is not case sensitive. You can use any of the following operators:
|
Ticket Reopens
(Not available on Team plans) |
The number of times a ticket has moved from Solved to Open or Pending. |
Ticket: Agent replies
(Not available on Team plans) |
The number of public agent replies to a comment from another customer or agent. |
Ticket: Assignee stations
(Not available on Team plans) |
The number of different agents to which a ticket has been assigned. |
Ticket: Group stations
(Not available on Team plans) |
The number of different groups to which a ticket has been assigned. |
Ticket: Number of incidents | This condition takes an action when the number of incidents on a problem ticket hits a threshold. |
Ticket: Within business hours?
(Not available on Team plans) |
Yes or No. This condition is available if an administrator has set business hours.
If you are on an Enterprise plan and have multiple schedules, the "within business hours" conditions are based on the schedule that is applied to the ticket (see Applying your schedules to tickets). |
Ticket: On a holiday?
(Not available on Team plans) |
This is set to yes during the full day of the holiday, not just during your normal business hours that day. If you have multiple schedules (Enterprise plans only), this condition respects the list of holidays set in the schedule applied to the ticket. |
Ticket: Schedule
(Enterprise plans only) |
If you have set up multiple schedules, this is the schedule applied to the ticket. The available values are the names of your schedules. |
Ticket: Within (schedule)
(Enterprise plans only) |
If you have set up multiple schedules, this enables you to compare the ticket update time to any schedule, not just the schedule applied to the ticket. The available values are the names of your schedules. |
Ticket: Custom fields | Checkbox, drop-down, and date custom fields are available as conditions. For all other custom field types, you can only check to see whether a value is present or not. |
Ticket: Side conversation
(Not available on Team plans) |
You can create trigger conditions for side conversations so that assignees know when a side conversation is created, closed, replied to, and reopened. Without them, the agent assigned to the ticket (who, ideally, is also the creator of the side conversation) may have a hard time knowing what’s going on with a particular issue. You can use these trigger condition statements with side conversations:
|
Requester: Language | Returns the language preference of the person who submitted the request. |
Requester: Role | The role of the ticket requester. The role type can either be agent, admin, or end-user. |
Requester: Number of Twitter followers | This is the number of the requester’s Twitter followers. |
Requester: Number of tweets is | This is the total number of the requester’s tweets. |
Requester: Is verified by Twitter | This condition is used to verify that the requester is a verified Twitter account. |
Requester: Time zone | The time zone of the ticket requester. |
Requester: Custom fields | Custom user fields are available as conditions. |
Organization: Custom fields | Custom organization fields are available as conditions. |
Current user |
You can select any of the following for the type of user that last updated the ticket: (agent) is a support staff member. (end user) is anyone who is a registered user and not an agent or an administrator. They can only submit and track tickets and communicate with agents publicly (meaning their comments can never be private). Agent name is the actual name of an agent. |
Ticket sharing: Sent to | Checks whether a ticket was shared to another Zendesk via a specific ticket sharing agreement. |
Ticket sharing: Received from | Checks whether a ticket was shared from another Zendesk via a specific ticket sharing agreement. |
Building trigger action statements
Action | Description |
---|---|
Ticket: Status |
The ticket status can be set to the following: New is the initial status of a newly created ticket (not assigned to an agent). Open means that the ticket has been assigned to an agent. Pending is used to indicate that the requester has been asked for information and the ticket is therefore is on hold until that information has been received. On-hold means that the support request is awaiting a resolution from a third party—someone who is not a member of your support staff and does not have an agent account in your Zendesk. Solved indicates that the customer’s issue has been resolved. The ticket is solved even if required ticket fields are still blank. See Required fields and automations. Tickets remain solved until they are closed. When tickets are closed is based on business rules you define for this step in the workflow, using automations. Closed means that the ticket has been locked and cannot be reopened or updated. |
Ticket: Form
(Enterprise plans only) |
Your ticket forms are available as actions. Select a specific form.
See Creating ticket forms to support multiple request types. |
Ticket: Priority | The priority can be set to Low, Normal, High or Urgent |
Ticket: Type |
The type can be set to the following: Question Incident indicates that there is more than one occurrence of the same problem. When this occurs, one ticket is set to Problem and the other tickets that are reporting the same problem are set to Incident and linked to the problem ticket. Problem is a support issue that needs to be resolved. Task is used by the support agents to track various tasks. |
Ticket: Group |
You can set groups to any of the following:
Additional value for macros:
|
Ticket: Assignee |
You can set the assignee to any of the following:
Additional value for triggers and macros:
|
Ticket: Satisfaction | You can set this action to: offered to requester. This indicates that the survey request has been sent to the ticket requester. |
Ticket: Set tags | The tags you want to insert into the ticket. The set tag action deletes all tags currently applied to the ticket, or associated with any ticket fields, and replaces them. Tags must be separated with spaces. |
Ticket: Add tags | The tags you want to add to the existing list of tags (if any). Tags must be separated with spaces. |
Ticket: Remove tags | The tags that you want removed from the existing list of tags contained in the ticket (if any). Tags must be separated with spaces. |
Ticket: Add cc | Add an agent or the current user to copy on the ticket update. This action is available when you enable CCs on tickets. |
Ticket: Set schedule
(Enterprise plans only) |
Your schedules are available as actions. Select Ticket: Set schedule, then select a specific schedule. When you set up multiple schedules, you must create triggers to apply your schedules to tickets. |
Ticket: Custom fields | Checkbox, drop-down, and date custom fields are available as actions. |
Notifications: Email user |
You can set the email user to any of the following:
Additional values for triggers:
Adding the email user action allows you to enter the email subject and body text. Body text can be formatted using HTML or placeholders. See Using placeholders for more information on formatting with placeholders. If you select a different notification destination when editing a trigger, the body text will reset. |
Notifications: Email group |
You can set email group to any of the following:
If you select a different notification destination when editing a trigger, the body text will reset. |
Answer Bot | Create a trigger that will launch Answer Bot when a ticket is submitted.
For more information about Answer Bot triggers, see Enabling, disabling, and setting up Answer Bot. |
Tweet requester | Respond to the Twitter requester with a Tweet. An @mention, and shortened ticket URL are added to the message so make sure to stay within the maximum Tweet length. |
Text user | If you are using Zendesk Text, you can configure a text to be sent to the user when the trigger conditions are met (see Using Text notifications with triggers: Recipes and tips). |
Text group | If you are using Zendesk Text, you can configure a text to be sent to a group of users when the trigger conditions are met (see Using Text notifications with triggers: Recipes and tips). |
Notifications: Notify target | Set the external target to notify. For more information about using targets, see Notifying external targets.
If you select a different notification destination when editing a trigger, the body text will reset. |
Requester: Language | Set the requester's language to one of your supported languages. |
Requester: Custom fields | Custom user fields are available as actions. |
Organization: Custom fields | Custom organization fields are available as actions. If the trigger includes this action, but the ticket isn't associated with an organization, the trigger does not fire. |
76 Comments
I know this is a newb question, but what would be the difference between "Ticket Status is New" vs "Ticket is Created"? (By default, aren't all created tickets New?) And why would I choose one over the other?
@Andrea - Great question! The difference is, not all tickets are new upon CREATION depending on your setup and use of Zendesk -- in our instance, many times we are the the phone with a customer, create the ticket for them, resolve it on the phone and set the the ticket to Pending or Solved upon creation!
Likewise, you can update a ticket in New status and it doesn't change from New, particularly if it's being rerouted to another group or a Private note being added for whatever reason.
So a ticket can be created and be in any status and a ticket in New status can also have an update and stay in New status (except if it was assigned or manually changed to a different status...)
THEREFORE... rounding 3rd base here. In some triggers, I want it to run the moment the ticket is created, no matter what status. Like, if a ticket is created and any word says "unhappy" I want the system to email the Customer Service Manager immediately so he/she can get on it quick.
And in some triggers, I want to just tend to New tickets - like, if an agent doesn't attend to a ticket in 5 hours since it was last actioned on by my receptionist who does some triage before the Customer Service agents, then i want to set that time from the last update on that ticket which should also still be in new status. Actually, in this last example it would be an Automation (time-based) but I hope you get my meaning.
Hope that makes sense!
Can i set up a "Ticket: Comment text" filter for URLs in the comment text of a ticket? Consider my options are:
If I wanted to filter by a url such as "acme.com/pricing" where present in the Ticket Comment, can I set up the following:
[Ticket: Comment text] [Contains not the following string] [acme.com/pricing]
Realize this is an edge case, and for purposes of this question the [Received at] [is not] [acme.com/pricing] filter by domain is not applicable. So I need to know - can URLs can be recognized as strings or words in comment text?
Hi Bora!
I've never done this specifically, but I don't see any reason why it wouldn't work. I'd recommend doing some testing on trigger to make sure it works, but I think you should be find.
The only option I am seeing when creating a trigger is "ticket" "is". where are all the other conditions? I want to create a trigger for a tag.
Hi Lori -
What plan type are you on? If you're on Essential, you only have access to the default triggers and conditions related to those triggers. Those triggers are outlined here: About the Support default triggers
Is there a way for me to activate the trigger when the status doesn't change from a specific status?
So for example.
We have a webhook script running that may only be called when the trigger is sent again with the status solved.
I looked at the conditions and there is not really something that gives me the feeling that is should be used for my usecase.
The one thing that might be it but I really don't know for sure is the following :
`status` -> `is not changed from` -> `solved`.
Hey Wouter!
As long as the condition in the trigger is Status > is > Solved (rather than Status > changed to > Solved, the trigger will run any time the ticket is updated with a Solved status. This goes for any ticket status.
Hello Jessie,
But that also means the trigger will run when it is set to update for the first time.
We would like to only run the trigger when the status was solved and is submitted again as solved.
So it doesn't change the status.
Hopefully this makes actual sense.
If this is not possible I will change the webhook script :)
Hi Wouter, You're right. I think I would try the `status` -> `is not changed from` -> `solved` condition as you mentioned earlier. I would test it for sure! Let us know how it works out.
Hi,
My question is about how to implement a change if a certain condition is changed.
Priority field has 4 values; Urgent, High, Normal, Low.
My Org wants that when the ticket priority is changed, a tag on that ticket must change with it.
Eg;
How can I implement that?
Thanks!
Hi @Anurag
You're not the only one that wants this kind of thing. Happens all the time. I'm not sure if you're just using the Sev1/Sev2/Sev3/Sev4 tags as stand alone tags or not, this might change slightly if those tags are associated with a custom field-- Assuming they are stand-alone tags:
Trigger 1
Upon Ticket Update
Priority is changed to -normal-
Remove tags sev1, sev3, sev4
Add tags sev2
Trigger 2
Upon Ticket Update
Priority is changed to -Low-
Remove tags sev2, sev3, sev4
Add tags sev1
Do the same for the other 2 priority changes.
That should do the trick! Hope this helps.
@Heather R
Thanks for the quick response.
I'll be using them as stand-alone tags.
I was thinking more on the lines of having 1 single trigger to facilitate this. Would that be possible?
Thanks!
@Anurag,
I don't think one trigger for this is possible.... You might be lucky there's only 4! Some of my processes take many more than four! :D)
@Heather R
Wow, that would be complex!
Thanks for the help on this though. I've already implemented this per your suggestion. Have a good day!
Hello Brian,
So from what you described, this should be 100% possible. You would need one trigger for the state and one for the country as they are separate tags, but aside from that detail, you should be able to accomplish this without the need of a third party app or custom code. Let me know if there is anything else I can assist you with and have a great day!
Hey Devan,
Thanks for the response. But I am still a bit unclear how you can pull it off without building a single trigger for each county and state. Is that what you are suggesting? I would have over 200 triggers for setting just this one field.
Instead, I am trying to build one list on the Organizational level now, and have it as an Organization Field that would auto-fill once a requester was selected (saving me trigger builds). The only thing I am worried about is if n custom organizational field can be referenced when trying to populate a field in Jira.
Are light agents considered "non-restricted agents" in the sense that if a trigger is added to email "all non restricted agents" would they be notified?
Hey James,
Light-agents would be considered a restricted agent, therefore they would not get a notification using the "non-restricted agents" action. If you would like to notify the light-agent, you can try using the Notify Group action which would notify them if they belong to the appropriate group.
Otherwise CC'ing them to the ticket would also send them a CC notification email.
Hope this helps!
Hi,
While creating a Trigger, In Conditions, if i select "Subject text" &"Contains the following string", Is it possible to use Regular expression in text box.. for ex: to filter the subject that starts with "IT" can i enter as ^IT* ?
Hi Ahamed,
You won't be able to use regular expressions with the Subject text" &"Contains the following string condition. If you attempt to use ^IT* your trigger will look for that exact string.
Let me know if you have any other questions!
Is there a feature/task/trigger that we can use that would serve as a reminder to work on a certain ticket
exampl;e is if we have not replied to a ticket for a month.
task would be: "update customer"
Hello,
Will a trigger based on Organizations only fire on the default organization?
Use Case:
We have two teams in one instance and we each have our own VIP end users that we want specific actions to occur. We notice if the VIP org we created is not the default, the triggers will not run.
Thank you!
Hi Nicole,
That is correct. The triggers run on the organization that is attached to the ticket.
If that isn't the default organization, those won't run.
The way around that is create a separate user field. For instance a checkbox or dropdown which says
If checked, once this user creates a ticket, the tag of that user field is inherited to the ticket.
Thus you can use that tag in a trigger.
- Kay
Hi Nicole,
The Trigger will fire off on the tickets associated to the given organization, so if the ticket is auto-created via email or something, it selects the default Organization and yes, that will result in the Trigger not firing if it's configured to fire off a different set of conditions/Organization settings.
If your agent is working in the Zendesk interface creating the ticket and correctly selects the given Organization when creating the ticket, you'll be fine :D
If you need this to work on the user regardless of what Organization, I would base my triggers on user profile settings, so create fields on the User level and leverage those. Would that work for you?
It would be probably an edge case, but is there any possibility to ignore all the text after some specified string so the trigger won't launch if it finds some words after that specific string?
For example if someone replies to mail, I would like to set the subject of the mail as the string after which all the text is ignored by the trigger so I can do word spotting in the reply of the customer excluding of the email to which he answers and which is displayed in the ticket.
Also would be useful if I could ignore some strings in the text - the case is I want the trigger to launch if there is a word for example language I want to launch the trigger. But I don't want to launch it in case there is a string system language so I want to get this string ignored and launch the trigger if the word language is somewhere else in the text.
Thank you for any recommendations. Would be much appreciated.
Sounds like we want regex matching. This would be the most flexible. I'd give my +1 ;)
Oliver
Hey Matus,
I did some digging on my end but I wasn't able to track down a way to accomplish what you're looking for. Triggers will look at the full text of the ticket update to check if it contains a keyword or certain string.
Perhaps someone else can jump in and offer up an alternative solution for you.
Regards
Hello
I have a question based on the text in this article that I quoted below. Why is it not required to select a problem when selecting the ticket type as "incident"?
I ask this because if a teammate forgets to select a problem then the ticket does not show up in our views, which are set to not view incidents (I have a system using a custom checkbox field that shows in our views if problems have incidents attached). I am faced with developing a workaround of some kind to collect the "vanished" incidents - easy enough to set up but it begs the question why? It seems that incidents are indeed defined as issues that have more than one occurrence so I do not understand why it is allowed to save a ticket as an isolated incident instead of making the selection of "problem."
-------
"Incident is used to indicate that there is more than one occurrence of the same problem. When this occurs, one ticket is set to Problem and the other tickets that are reporting the same problem are set to Incident and linked to the problem ticket."
Hey Kevin,
In some cases an incident may be created which doesn't require being attached to an overall problem ticket. For example, we use the Incident type if someone contacts us stating they're unable to log into their account. This doesn't necessarily mean that all users are unable to log into their accounts. Instead this could be an account-specific issue and does not require a problem ticket. This is why we make this field optional instead of a requirement.
Let me know if this doesn't make sense.
Cheers!
Please sign in to leave a comment.