This article describes the different conditions and actions you can use when creating ticket triggers. For information on creating new ticket triggers, see Creating ticket triggers for automatic ticket updates and notifications.
This article contains the following sections:
Building ticket trigger condition statements
Condition statements consist of conditions, field operators, and condition values. Available values 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 |
---|---|
Object | |
Ticket: Agent replies (Not available on Team plans) |
The number of public agent replies to a comment from another customer or agent within Support tickets. |
Ticket: Assignee |
The assignee values are:
Additional value for views:
|
Ticket: Assignee stations (Not available on Team plans) |
The number of different agents to which a ticket has been assigned. |
Ticket: Attachment | This condition checks whether or not the ticket update has any attachments. Both appended and inline attachments are included, with the exception of inline attachments that are added to the ticket using a macro. |
Ticket: Brand (Not available on Team plans) |
Checks whether a ticket is associated with the specified brand. |
Ticket: CC | This condition checks whether or not the ticket has any CCs on it at the time the trigger runs. It does not check for followers or @mentions. |
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 the ticket channels you can configure, see About Zendesk channels and Understanding ticket channels in Explore. |
Ticket: Channel name | The name of the messaging channel through which the ticket was created. All active social, web, and mobile messaging channels appear in the list. |
Ticket: Comment |
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:
Note: In most languages, words are separated by spaces. When providing words or
strings in Han, Katakana, Hiragana, Kanji, or Hangul characters, spaces aren't
used as word boundaries except around any Arabic numerals that are
included.
|
Ticket: Due date | Checks whether a due date is or isn't present for the ticket. |
Ticket: Custom fields | Custom fields support a subset of operators that vary by custom field type.
For all custom field types, you can check to see whether a value is present or
not. Additionally,
All ticket lookup relationship fields can be selected under Lookup relationships. All other types of custom fields on a ticket are available under Tickets. |
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: Group |
The group values are:
Additional value for views:
|
Ticket: Group stations (Not available on Team plans) |
The number of different groups to which a ticket has been assigned. |
Ticket: Integration account | This condition checks the integration account that the ticket came from, such
as a specific Facebook page, X (formerly Twitter) handle, or other channel
integration account, like Google Play. Select one of your configured integration
accounts from the drop-down menu.
Note: If there are multiple accounts defined for
the same channel type (for example, WhatsApp), tickets can be routed only by
channel type, not by a specific integration account.
|
Ticket: Intent | An AI prediction of what the ticket is about. To see the possible values,
open the Taxonomy tab of the Intent settings
page to see the AI Intents list under the Taxonomy values
heading. This condition is available as part of intelligent triage. Does not work with the Ticket | Is | Created condition. See Why didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Intent confidence | How likely it is that the intent prediction is correct. Values are
High, Medium, and Low. This condition is available as part of intelligent triage. Does not work with the Ticket | Is | Created condition. See Why didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Language | An AI prediction of what language the ticket is written in. To see the
possible values, you can go to the Taxonomy tab of the
Language settings page. This condition is available as part of intelligent triage. Does not work with the Ticket | Is | Created condition. See Why didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Language confidence | How likely it is that the language prediction is correct. Values are
High, Medium, and Low. This condition is available as part of intelligent triage. Does not work with the Ticket | Is | Created condition. See Why didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Number of incidents | This condition takes an action when the number of incidents on a problem ticket hits a threshold. |
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: 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: Privacy | This condition lets you test if a ticket has public comments or not. You can
select either:
|
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 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. This condition will work only if the support email address is a valid user address. This condition could be met by an email address in the CC field if it's associated with a user account. Email addresses that aren't associated with a user account (such as Google Groups, aliases, and distribution groups) can't satisfy this condition when in the CC field. Note that this condition doesn't check the channel from which the ticket originated and can be true for tickets that weren't received through email. For example, when using the Select an Address app you can specify a recipient email address and therefore meet this condition even though the ticket was created in the agent interface. If you're using this condition with your main Zendesk support address (the same as your subdomain), the trigger will still fire if an email is received at a different external support address you've configured. This is because all emails received are redirected to your default support address. |
Ticket Reopens (Not available on Team plans) |
The number of times a ticket's status changed from Solved to Open or Pending. |
Ticket: Satisfaction (Not available on Team plans) |
This condition returns the following customer satisfaction rating values:
|
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: Sentiment | An AI prediction of how the customer feels about their request. Values are
Very Positive, Positive, Neutral, Negative, and
Very Negative. This condition is available as part of intelligent triage. Does not work with the Ticket | Is | Created condition. See Why didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Sentiment confidence | How likely it is that the sentiment prediction is correct. Values are
High, Medium, and Low. This condition is available as part of intelligent triage. Does not work with the Ticket | Is | Created condition. See Why didn’t my intelligent triage trigger run during ticket creation? |
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:
|
Ticket: Status category |
Note: If you’ve activated custom ticket statuses, system
ticket statues and any ticket statuses you create are grouped into status
categories. Each status category has a default ticket status. See Managing ticket statuses.
The status category values are: New is the initial status category of a newly created ticket (not assigned to an agent). The Open status category is for grouping ticket statuses that indicate when tickets are ready to be worked on by your support team. The Pending status category is for grouping ticket statuses that are used to indicate that the support team is waiting for the requester to reply. The On-hold status category contains ticket statuses used to indicate 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 category is optional and must be added to your Zendesk (see Adding on-hold ticket status to your Zendesk).The Solved status category contains ticket statuses that indicate that the customer’s issue has been resolved. The Closed status category contains the Closed system ticket status that indicates that the ticket has been locked and cannot be reopened or updated. When selecting a status category, you can use the field operators Less Than and Greater Than to specify a range of tickets based on their status category. New is the lowest value, with values increasing until you get to Closed status category. For example, a condition statement that returns tickets only in the New, Open, and Pending caetegories looks like this: Status category is less than Solved. |
Ticket: Status |
Note: If you’ve activated custom ticket statuses, existing
standard ticket statuses become status categories. If you have existing conditions
that use Status, they’re updated to the corresponding Status category.
The standard 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 account. This status is optional and must be added (see Adding the On-hold ticket status). 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: 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:
This condition is not available if the Subject field has been deactivated. |
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: 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. |
Ticket: Ticket status | If you’ve activated custom ticket statuses, you can select system
ticket statuses and new ticket statuses you created as conditions. When selecting a ticket status, you can use the field operators Contains at least one of the following and Contains none of the following and specify multiple ticket statuses. For example, a condition statement that returns tickets with either a specific new or system ticket status may look like this: Ticket status Contains at least one of the following: Open, Dev assigned, Escalated. |
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: 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). Autoreply events can't be reliably identified by this condition. Agent replies submitted through the standard interface or Agent Workspace are recorded as updated via the Web channel. In the Agent Workspace, they will appear as updated via Email, but triggers still recognize them as updated via Web. Bulk updates to tickets from the Support interface are recorded as updated via a Web Services (API) channel. |
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: Within (schedule) (Enterprise plans only) |
If you have set up multiple schedules, this activates 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. |
Lookup relationships | |
Custom object: Custom object (record) | For custom objects related to tickets, the custom object's records are available as conditions. |
Custom object: Custom field | For custom objects related to tickets, the custom object's fields are
available as conditions. Custom date field conditions always refer to calendar days; business hours and schedules aren't considered. |
Organization: Organization (record) |
The organization values are:
|
Organization: Custom fields | Custom organization fields are available as conditions. If the trigger
includes this condition, but the ticket isn't associated with an organization, the
trigger does not fire. Custom date field conditions always refer to calendar days; business hours and schedules aren't considered. |
Requester: Requester (record) |
Checks the Requester field on the ticket. The requester values are:
Additional value for views:
|
Requester: Custom fields | Custom user fields are available as conditions. Custom date field conditions always refer to calendar days; business hours and schedules aren't considered. |
Requester: Is verified by X Corp | This condition is used to verify that the requester is a verified X (formerly Twitter) account. |
Requester: Number of X Corp followers | This is the number of the requester’s X (formerly Twitter) followers. |
Requester: Number of tweets | This is the total number of the requester’s tweets. |
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 be agent, admin, or end-user. Additionally, if you're using light agents, the light agent role type is available. |
Requester: Time zone | The time zone of the ticket requester. |
Ticket: Lookup relationship fields | Ticket lookup relationship fields are available as conditions. |
Ticket details | |
Current user | You can select any of the following for the type of user that last
updated the ticket:
If a ticket is created by an internal system event such as voicemail, the Current user condition is not applied. When a voicemail ticket is created, the first comment on the ticket is added by Support as a private comment and includes the voicemail recording, but Support doesn't interpret the comment as being from a user. The Current user condition is not supported when the ticket is from a messaging channel. |
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 ticket trigger action statements
Action | Description |
---|---|
Object | |
Ticket: Add follower | Add an agent or the current user as a follower on the ticket update. This action is available when followers are enabled on tickets. When followers are enabled, the Ticket: Add follower action replaces the Ticket: Add CC action. |
Ticket: Add skills | The skills you want to add to a ticket and whether they are required or can time out. Any existing skills on the ticket are unaffected. This action is available when omnichannel routing is enabled and you've created at least one skill. |
Ticket: Add tags | The tags you want to add to the existing list of tags (if any). Tags must be separated with spaces. |
Ticket: Assignee |
You can set the assignee to any of the following:
Additional value for triggers and macros:
|
Ticket: Autoreply (Advanced AI add-on only) |
Add a public comment to the ticket to attempt to directly answer the
customer’s request. For more information about using this action, see Adding a public comment to a ticket using a trigger. |
Ticket: Brand (Not available on Team plans) |
Add a brand to the ticket. |
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: Custom fields | Checkbox, drop-down, text, number, and date custom fields are available as
actions. Custom date field actions always refer to calendar days; business hours and schedules aren't considered. |
Ticket: Group |
You can set groups to any of the following:
Additional value for macros:
|
Ticket: Internal note (Advanced AI add-on only) |
Add an internal note to the ticket. For more information about using this action, see Adding an internal note to a ticket using a trigger. |
Ticket: Priority | The priority can be set to Low, Normal, High or Urgent |
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: Satisfaction | You can set this action to: offered to requester. This indicates that the survey request has been sent to the ticket requester. |
Ticket: Remove skills | The skills you want to remove from the ticket. This action is available when omnichannel routing is enabled and you've created at least one skill. |
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: Set skills | The skills you want to insert into the ticket and whether they are required or can time out. The set skills action deletes all skills currently applied to the ticket and replaces them. This action is available when omnichannel routing is enabled and you've created at least one skill. |
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: Share ticket with (Enterprise plans only) |
Share the ticket with the specified account. Requires that a ticket sharing
agreement be in place. See Sharing tickets with other Support accounts and Using business rules to share tickets. |
Ticket: Side conversation via email (Not available on Team plans) |
Create an email side conversation. Available only when email side conversations are enabled. When using this action, you must include content in the email message for the side converation to be created. We suggest also adding a Ticket: Add tags action that adds a tag, such as "triggered_sc" that can be used in a Tags | Contains none of the following | triggered_sc condition to prevent triggers from creating unnecessary side conversations.
Note: When using this action, the Side
conversation | is | Created condition is suppressed.
|
Ticket: Side conversation via child ticket (Not available on Team plans) |
Create a child ticket side conversation. Available only when child ticket side conversations are enabled. It's best to use a ticket that is already assigned to an agent as the parent ticket. If a child ticket is created for a parent ticket that hasn't been assigned to an agent or group, the child ticket's requester is set to the Zendesk System User. It's also best practice to include an action that assigns an agent or group for the child ticket created by this action. When using this action, we suggest also adding a Ticket: Add tags action that adds a tag, such as "triggered_sc" that can be used in a Tags | Contains none of the following | triggered_sc condition to prevent triggers from creating unnecessary side conversations.
Note: When using this action, the Side conversation | is |
Created condition is suppressed.
|
Ticket: Status category |
Note: If you’ve activated custom ticket statuses, system
ticket statues and any ticket statuses you create are grouped into status
categories. Each status category has a default ticket status. See Managing ticket statuses.
When you use a status category as an action, the ticket status is set to the category's default ticket status. The status category values are: New is the initial status category of a newly created ticket (not assigned to an agent). The Open status category is for grouping ticket statuses that indicate when tickets are ready to be worked on by your support team. The Pending status category is for grouping ticket statuses that are used to indicate that the support team is waiting for the requester to reply. The On-hold status category contains ticket statuses used to indicate 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 category is optional and must be added to your Zendesk (see Adding on-hold ticket status to your Zendesk).The Solved status category contains ticket statuses that indicate that the customer’s issue has been resolved. The Closed status category contains the Closed system ticket status that indicates that the ticket has been locked and cannot be reopened or updated. |
Ticket: Status |
Note: If you’ve activated custom ticket statuses, existing system ticket
statuses become status categories. If you have existing actions that use Status,
they’re updated to the default status of the corresponding Status
category.
The system ticket status values 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 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: Ticket status | If you’ve activated custom ticket statuses, you can specify actions that set the ticket status to a new or system status. |
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. |
Lookup relationship | |
Custom object:Custom object (record) | Select a custom object record to relate to the ticket. |
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. Custom date field actions always refer to calendar days; business hours and schedules aren't considered. |
Requester: Language | Set the requester's language to one of your supported languages. |
Requester: Custom fields | Custom user fields are available as actions. Custom date field actions always refer to calendar days; business hours and schedules aren't considered. |
Ticket: Lookup relationship fields | Ticket lookup relationship fields are available as actions. |
Other | |
Notify by: Active webhook | Set the active webhook to notify. For more information about using webhooks, see Creating a webhook. If you select a different notification destination when editing a trigger, the body text will reset. |
Notify by: Autoreply with articles | Sends an automated email response to the customer's request. The email
contains help center article suggestions to help the customer resolve their
issue. For more information about email autoreplies, see Configuring email autoreplies to deflect requests. |
Notify by: External 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. |
Notify by: Group email |
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. |
Notify by: Group text | 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). |
Notify by: Request messaging rating | Sends an automated satisfaction survey at the end of the conversation. See About CSAT ratings in messaging. |
Notify by: Tweet | Respond to the X (formerly 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. |
Notify by: User email | You can set the email user to any of the following:
Additional values for triggers and automations:
The email notification is sent only if the update includes a public comment. If the update has a private comment or no comment, the trigger or automation can still fire other actions, but it won't send the notification. There's a known limitation for using the Email user + (requester and CCs) action and the Ticket + is + Updated conditions in triggers. When used together, Support suppresses emails to a user if the ticket update is from that same user. This is expected behavior to eliminate redundant emails. For more information about suppression, see Understanding suppression of CCs email notifications. 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 or automation, the body text will reset. |
Notify by: User text | 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). |
Notify by: Zendesk integration | When using the Slack for Zendesk Support integration, you can notify Slack users about Zendesk ticket events. Select Notify Zendesk integration and Slack integration from the drop-down lists. |