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. 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 most-recent comment of a ticket. Here's what's checked:
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. |
72 Comments
Hi Chris
Thanks for the answer. The reason it does not make sense to me is - using the example you gave - wouldn't someone not being able to login to their account be a "problem?" I was under the impression that everything is a problem and if there is more than one occurrence then you make additional occurrences incidents
Hey Kevin,
I can definitely see how it could work in both cases. There's more of an explanation on the relationship between Problem and Incident tickets here: Working with problem and incident tickets
Hey Chris
Without being too much of a pain, can you tell me why incident is defined in the way quoted in this article, and other Zendesk articles, if the intended use-case is that incident can either be attached to a problem or be stand-alone? Honestly, I think I wouldn't have had any of this confusion unless I read that. The same definitions of ticket type are also in "Creating Views To Manage Ticket Workflow"
I'd like to suggest that the definition quoted here is changed.
"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."
And
"Problem is a support issue that needs to be resolved."
Hey Kevin,
Thanks for the clarification! I agree that this could be worded better in our documentation. I've flagged the article for the appropriate team to look at :)
Thanks again for bringing this to our attention!
Fair enough, thank you Brett.
(also unsure why I was calling you Chris. My apologies)
No problem at all Kevin!
Why can't triggers use wildcards in tags like search can?
Hi Guys
I'm wondering is there any way that for the custom field, all the conditions available for default fields in trigger to be added somehow!?
To be specific, for example if you want to use "Status" in a trigger you have many options to select from the dropdown list as below:
But if you have a custom field, only few items are available! Without having all those conditions, the custom fields won't help as much as they could if they had more conditions to select from.
Hey Ethan,
Thanks for taking the time to share this with us! I'll be sure to pass this feedback along to the appropriate team so they're aware of this need.
Cheers!
Question regarding triggers - Is there there a way to only have the first trigger get processed and not the remainder of the triggers?
For instance, I have an RMM alerting system that sends emails to the Help Desk. There is a trigger setup to automatically reply to the originator. Unfortunately, the from address on the RMM does not accepts emails, so and NDR is received every time. Is there a away to exclude a particular address when a trigger is processed so that the NDR is not received?
Thank you
David
Hey David,
Just to confirm, are you trying to prevent the trigger from firing when the requester of the ticket is a specific user (RMM)? If so, you could just tag that user profile which will carry over to the ticket.
You can then set up your triggers to exclude any tickets that have the tagged set in the users profile.
Let me know if the above doesn't make sense!
Yes, that is exactly what I need to accomplish. How would I tag that user profile?
For instance, the from address is not a user already setup in Zendesk. IT is coming from an external email address.
Thanks
David
Hey David,
This article will walk you through those steps :) Automatically tagging tickets from specific users and organizations
I hope this helps!
Hi Friends - is there a way to trigger based on if the ticket was submitted/updated with an attachment attached? And also attachment name and/or extension?
Hi Naomi,
That particular condition is not currently available with triggers. However if customers were to select a custom field (perhaps a checkbox) if they intended to attach a file you could run a trigger based off of that.
I hope that is helpful!
hi Devan - Community Manager - Will tomorrow's AMA be in Zoom format? How do we keep up to date with the questions being asked?
Hi Naiomi,
I am so sorry we didn't respond to this prior to the AMA. Our AMAs are Reddit-style, meaning that they happen in the community forum in a written format (as opposed to on Zoom or other video format.)
You can simply visit the AMA topic to see each of the questions asked and the answers provided. Here's where you can see all of our past AMAs.
If I create a trigger that's based solely on a USER(Requester) level custom field, when will the trigger execute? Does the agent need to save any one of the user's tickets before the trigger will execute, or is there a way to have it execute when the user field is updated (which is what we'd prefer in this particular use case).
Hi pstrauss,
If there is a tag related to a user field, it won't push through to the ticket when that user field is updated. This field will cross over to the ticket when a new ticket is created, and the user field is already set. I hope that part makes sense.
If you were able to update the tickets in bulk with the same tag that is present with the user field (if it is a field that has a tag related to it) and have the trigger fire based off of the tag instead of the user field, you could have both use cases accounted for. I know that isn't exactly what you were looking for, but depending on the use case it could work out for you.
I hope this is helpful - please let us know if we can assist further!
Hi ZD community,
I'd like to ask you a question why it didn't trigger a created ticket with Requester: Custom fields(drop-down list).
Note: I just only used a condition in all tickets that meet the specified criteria.
Thanks in advance!
By Kyle
Hi YU-CHENG LI,
Can you provide some more detail about what you are trying to do?
What are the conditions of the trigger and when is the custom field you mentioned updated?
Hi Gail,
First of all, thanks for help me.
Then, my scenario is just like we'd like to trigger a created ticket(through the Extensions) after importing CSV file with custom fields(drop-down list). So I would set up a trigger with custom fields in all tickets that meet the specified criteria. However, nothing comes out as planned. It didn't work. That's why I confused about this condition. What's wrong with it?
Thanks in advance!
By Kyle
Hi Yu-Cheng,
When triggers don't fire it's because something in the conditions of the trigger doesn't match to the ticket that is created. What you need to do is review what the trigger is looking for compared to the ticket events on one of the ticket examples created by your target. For example if you have a trigger looking for custom field value for the ticket created, but the value of the field isn't set when the ticket is created, then the trigger won't fire.
A ticket created by importing values from a drop-down list will probably have pretty consistent formatting, so you might be able to link the trigger to keywords or string matches in the text or subject of the ticket that gets created.
I have set up a trigger that sends an auto email when someone emails our support@DOMAIN.zendesk.com. However now that I have added an external email address which forwards to this email (so that we get the emails as tickets in Zendesk), I want to ONLY trigger this when the email does NOT come from this new email address. There is no "received at" "is not" option, only an "is" option so how can I do this?
Thanks
Hi Fiona,
For this I think your best option will be to use the condition that the received at address is your support@yoursubdomain.zendesk.com address in the auto-reply trigger, that will get it to skip any tickets coming in the from the external address you've connected. I this only applies to the email tickets you can add that under "Meets all" conditions to limit it.
If you also have tickets coming in via you help center web form or the web widget that you also want the auto-reply sent for you could use "Meets any" conditions to list all of the places where you do want the trigger to fire by including the ticket channel conditions in addition to the received at condition.
I hope that helps!
Just to clarify:
>(agent) is a support staff member.
Does this mean all agents and light agents?
Thanks!
Hi Deborah,
Yes, any type of agent role (including light agents) will be included in that condition.
Hello,
I'm trying to set a trigger in order to put a tag on tickets that come from ''shared tickets''
I put 3 conditions in ''ALL these conditons are met'':
Ticket is created
Status is less than resolved
Subject text Contains at least one of the following words : look
Do I have to add another condition in order the trigger fires?
Thanks for your help
Is there anybody to help me with this issue please
Thanks
Hello Ouma,
Could you explain in more detail what you want to do?
By the way, just a side note -- be sure to use "Add tags" not "Set tags", unless you want to remove all other existing tags.
Please sign in to leave a comment.