This article describes the different conditions and actions available when creating automations. For information on creating new automations, seeCreating and managing automations for time-based events.
This article contains the following sections:
Building automation condition statements
As with triggers, the condition statements you create for automations contain conditions, operators, and values. These include conditions you’d expect such as priority, status, assignee and so on. Because automations are based on the hours that have elapsed since a ticket update was made, Zendesk provides the following time-based conditions:
- Hours since created
- Hours since open
- Hours since pending
- Hours since on-hold
- Hours since solved
- Hours since closed
- Hours since assigned
- Hours since update
- Hours since requester update
- Hours since assignee update
- Hours since due date (for tickets with the type set to Task)
- Hours until due date (for tickets with the type set to Task)
- Hours since last SLA breach
- 个小时,直到下一个SLA breach
- Hours since [ticket status name]Note:If you’veactivated custom ticket statuses, all the hours since [ticket status] conditions are updated to hours since [status category].
To learn more about how existing time-based conditions based on system ticket statuses are updated and how to use new ticket statuses you create in automations, seeUsing ticket statuses in business rules.
Note the following restrictions when using time-based conditions:
- Time-based conditions aren't available fromMeet any of these conditionssection of the automation creator (seeCreating and managing automations for time-based events). Automations require a nullifying condition to ensure that they aren't running continuously.
- Due daterefers to 12 PM in your account's timezone.
- Only whole numbers can be used as the value for these conditions. For example, Hours since created = (calendar) is = 1, is valid. Decimals aren't supported. If you set the hours since variable to 1.5, it will be interpreted as 1, which means that it was rounded down to the whole number.
- Hours since [status]conditions, such asHours since open, only fire if the ticket remains in that status or status category. For instance, if you create an automation that fires whenHours since open is 2, it will not fire if the status changes fromopentopendingbefore the two hours are up.
- Theiscondition forHours sinceapplies only for a certain timeframe. For example, if you create an automation that includesHours since solved is 24, but the automation runs after 24 hours have passed, the automation will not fire. Consider usingGreater thanorLess thanfor these types of conditions.
- Hours since updatemeans that any update to the ticket – including an automation firing – will update the ticket.
- Hours until > less thanconditions are inclusive (they include both "less than" and "equal to"). For example,个小时,直到下一个SLA breach > less than > 2can fire atexactlytwo hours before the SLA breach time. All other time-based conditions are exclusive.
| Condition | Description |
|---|---|
| Ticket: Status |
Note:If you’veactivated custom ticket statuses, existing system ticket statuses become status categories. If you have existing conditions that use Status, they’re updated to the corresponding Status category. The system ticket status values are: Newis the initial status of a newly created ticket (not assigned to an agent). Openmeans that the ticket has been assigned to an agent. Pendingis 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-holdmeans 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 (seeAdding on-hold ticket status to your Zendesk). Solvedindicates that the customer’s issue has been resolved. Tickets remain solved until they are closed. Closedmeans that the ticket has been locked and cannot be reopened or updated. When selecting a status, you can use the field operatorsLess ThanandGreater Thanto specify a range of tickets based on their status.Newis the lowest value, with values increasing until you get toClosedstatus. For example, a condition statement that returns only New, Open, and Pending tickets looks like this: Status is less than Solved. |
| Ticket: Status category |
Note:If you’veactivated 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. SeeManaging ticket statuses. The status category values are: Newis the initial status category of a newly created ticket (not assigned to an agent). TheOpenstatus category is for grouping ticket statuses that indicate when tickets are ready to be worked on by your support team. ThePendingstatus category is for grouping ticket statuses that are used to indicate that the support team is waiting for the requester to reply. TheOn-holdstatus 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 (seeAdding on-hold ticket status to your Zendesk).TheSolvedstatus category contains ticket statuses that indicate that the customer’s issue has been resolved. TheClosedstatus 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 operatorsLess ThanandGreater Thanto specify a range of tickets based on their status category.Newis the lowest value, with values increasing until you get toClosedstatus 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: Ticket status | If you’veactivated custom ticket statuses, you can select system ticket statuses and new ticket statuses you created as conditions. |
| Ticket: Form (Enterprise plans only) |
Your ticket forms are available as conditions. Select a specific form. |
| Ticket: Type | The ticket type values are: Question Incidentis 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. Problemis a support issue that needs to be resolved. Taskis used by the support agents to track various tasks. |
| Ticket: Priority | There are four values for priority:Low,Normal,High, andUrgent. 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:
附加价值的观点:
|
| Ticket: Assignee | The assignee values are:
附加价值的观点:
|
| Ticket: Requester | The requester values are:
附加价值的观点:
|
| 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 operatorsContains at least one of the followingorContains none of the following. More than one tag can be added. Tags must be separated with spaces. |
| Ticket: Description | The description is the first comment in the ticket. It does not include the text from the subject line of the ticket. If you are using theContains at least one of the followingorContains none of the followingoperators, the results will consider words containing part of the entered search terms. For example, using "none" for this condition will return (or exclude) ticket descriptions containing "nonetheless". The description condition also pulls data contained within the HTML and the original source of a ticket. |
| 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 channels you can configure, seeAbout Zendesk Support channelsandUnderstanding ticket channels in Explore. |
| 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 GooglePlay. Select one of your configured integration accounts from the drop-down menu. |
| 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 inForwarding incoming email to Zendesk Supportor the condition won't work. This condition will work only if the support email address is a real user address, this condition will not work for non-user addresses, such as Google Groups, aliases, and distribution groups, when the non-user support address is added in the CC field instead of the TO 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 theSelect an Address appyou can specify a recipient email address and therefore meet this condition even though the ticket was created in the agent interface. |
| Ticket: Satisfaction (Not available on Team plans) |
This condition returns the following customer satisfaction rating values:
|
| Ticket: Privacy | This condition checks to see if a ticket has public comments or not. You can select either:
|
| Ticket:Custom fields | Custom ticket fields are available as conditions. |
| Requester: Language | The language of the person who submitted the ticket. |
| Requester:Custom fields | Custom user fields are available as conditions. |
| Requester: Role | Adds a condition to your triggers to create a different workflow when the requester is an end user versus an agent. |
| Organization:Custom fields | Custom organization fields are available as conditions. If the automation has a condition like the following: Organization:field>Is not>value The statement will be true only if the ticket has an organization and that organization's field doesn't match. If the ticket does not have an organization, this type of condition will not be true. |
| 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 automation action statements
Action statements define what occurs if all the condition statements are true and the trigger fires. You can think of action statements as ‘then’ statements.Ifall of your conditions are truetheninvoke these actions to update the ticket and optionally send notifications.
| Action | Description |
|---|---|
| Ticket: Status |
Note:If you’veactivated 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: Newis the initial status of a newly created ticket (not assigned to an agent). Openmeans that the ticket has been assigned to an agent. Pendingis 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-holdmeans 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. Solvedindicates that the customer’s issue has been resolved. The ticket is solved even if required ticket fields are still blank. SeeRequired 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. Closedmeans that the ticket has been locked and cannot be reopened or updated. |
| Ticket: Status category |
Note:If you’veactivated 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. SeeManaging 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: Newis the initial status category of a newly created ticket (not assigned to an agent). TheOpenstatus category is for grouping ticket statuses that indicate when tickets are ready to be worked on by your support team. ThePendingstatus category is for grouping ticket statuses that are used to indicate that the support team is waiting for the requester to reply. TheOn-holdstatus 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 (seeAdding on-hold ticket status to your Zendesk).TheSolvedstatus category contains ticket statuses that indicate that the customer’s issue has been resolved. TheClosedstatus category contains the Closed system ticket status that indicates that the ticket has been locked and cannot be reopened or updated. |
| Ticket: Ticket status | If you’veactivated custom ticket statuses, you can specify actions that set the ticket status to a new or system status. |
| Ticket: Form (Enterprise plans only) |
Your ticket forms are available as actions. Select a specific form. |
| Ticket: Priority | The priority can be set toLow,Normal,HighorUrgent |
| Ticket: Type | The type can be set to the following: Question Incidentindicates 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. Problemis a support issue that needs to be resolved. Taskis 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 | 你想要的标签从现有的list of tags contained in the ticket (if any). Tags must be separated with spaces. |
| Ticket: Add cc | Add an agent on the ticket update. This action is available when you activate CCs on tickets.. |
| Ticket:Custom fields | Custom ticket fields are available as actions. |
| Ticket: Share ticket with | Share the ticket with the specified account. Requires that a ticket sharing agreement be in place. SeeUsing business rules to share tickets. |
| Notifications: Email user | 你可以设置任何下列电子邮件用户:
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 theEmail user + (requester and CCs)action and theTicket + is + Updatedconditions in triggers and 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, seeUnderstanding 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. SeeUsing placeholdersfor more information on formatting with placeholders. If you select a different notification destination when editing a trigger or automation, 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. |
| Notifications: Notify active webhook | Set the active webhook to notify. For more information about using webhooks, seeCreating a webhook. If you select a different notification destination when editing a trigger, the body text will reset. |
| Notifications: Notify target | Set the external target to notify. For more information about using targets, seeNotifying external targets. If you select a different notification destination when editing a trigger, the body text will reset. |
| Notifications: 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. |
| 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. |
31 Comments
Will automations ever be brought up to par with triggers? The automation build page is archaic. Not being able to search for the conditions/actions is so difficult, especially when you have a lot of custom ticket fields like my company. I just spent 10 minutes building a trigger that should have took me 1 because of having to comb through the drop-down list.
I'm building an automation that requires Ticket: Assignee Is (—).
Per the above documentation, this should work. However even copy/pasting "(—)" into the dropdown returns "Sorry, no results found." How can I work around this?
The same thing happened on my account@...- it looks like once you have a high amount of agents you would want to click the "### other results. Try refining your search." option at the bottom of the drop-down menu, which fills the field with "-"
Not exactly intuitive design, but hopefully it works. Waiting for a test ticket to run its course as a confirmation
@...Yep, that worked. The option I had to click on said, "99 other results. Try refining your search." Simply clicking that populated the field with -
This is such a bizarre UI decision, I'm sure it's an oversight.
Thanks for the tip!
for anyone who's wondering, the 'hours since open/pending' automations are based on continuous hours. Changing the status to open if it was pending resets the counter. We use this internally to bring tickets back into open status for proactive work after x days in pending, which would never work if the counter was looking at total open/pending hours.
The guide for how Ticket Channels are defined across zendesk links to a hidden/removed page.
This part;
Please fix this.
Thanks for the heads-up, Patrick! I'll alert our documentation team.
Hi Patrick! Thanks for letting us know about that. I've made a slight update to this part of the article.
Hi! I see it's possible to write automation rules based on whether a date parameter "is within the previous" number of days. Is it also possible to write the opposite somehow? (i.e. "is NOT within the previous" number of days).
Hey@...! Currently, there is not an option for "is NOT within the previous" for date conditions.
I encourage you to create a new post in theSupport Product Feedback topicin our community to engage with other users who have similar needs and discuss possible workarounds. Conversations with a high level of engagement ultimately get flagged for product managers to review when they go through roadmap planning.
具体的例子,细节的影响,以及如何you currently handle things are helpful for our product teams to understand the full scope of the need when working on solutions.
We need to have all unsigned tickets auto-assigned to an agent at a certain time, e.g., at 16:30 at the day. I searched event created a trigger or automation by applying today() function but don't find a way.
Any suggestion?
Thank you for reaching out to Zendesk Support.
In regards to your concern, automationruns every hour on all your tickets that are not closed. If you're looking to auto-assign all of your open tickets to a specific agent, you can have a similar setup for automation:
You cannot set a specific time since automation only runs every hour. There's an option as well for a condition, Ticket: Hours since created. It would depend on your workflow. You can check all the available conditions once you go to the automation.
You can also check our article,Automations resources and recipesfor all the resources available for the creation of automation.
Thank you and have a wonderful day ahead!
Kind regards,
Is there a condition we can use to run automations only on tickets with reply from an agent or without such reply?
Automations does not have any condition that will match your case, but you can check the Trigger conditions to see if it will fit your workflow. There are Trigger conditions that can check for ticket comments as you would see here :
https://support.zendesk.com/hc/en-us/articles/4408893545882-Trigger-conditions-and-actions-reference
Depending on your use-case, you can utilize both Triggers and Automations but that would depend on how you're going to set it up.
How do you use an automation to check or uncheck a box on the user. I have an automation set up to look at the check box and if the box is checked meets a time requirement of time since requester was updated and the ticket has a specific tag to uncheck the box. However, it is not unchecking the box.
Does your custom user checkbox include a tag? If your checkbox does not add a tag when checked, it will not work in automations.
Thanks!
It does add a tag.
I've gone ahead and created a support ticket for us to look at this directly with you to make sure we can better assist. (:
Is anyone else having problems with the "Hours since assignee update" condition? It's been part of an automation that I've used for 6 years, but seems to have stopped working recently.
The condition was set to (business) Greater than 16. I pressed the "Preview match for the conditions above", and nothing appeared. I changed it to 1 hour, then 0 hours, and still nothing. Once I removed it completely, tickets that hadn't been touched in OVER A MONTH appeared in the preview.
HiDavid Templeton!
I went ahead & created a ticket for you since this might need further troubleshooting. Please keep an eye out for our advocate's email!
Is there any information on how conditions work with date custom fields? For example, if I set up a condition for "is in next 1 day" what time does it consider the condition met.
Is within the previousandIs within the next把一个整数的天数,在背面end is translated into multiples of 24 hours.
For example,Custom date field | Is within the next | 3means the condition will evaluate as true when the timestamp of the custom date field is within the next 72 hours.
The timestamps for date fields are a more complicated issue since they’re not exposed anywhere in the UI or the API. At this time, automations use UTC timestamps for custom date field conditions. They don't use the account's local time zone. That can lead to automations appearing to fire several hours early or late, depending on how far the account is from UTC.
I hope this information helps. Thank you!
Hello,
I need to add a condition in my automation using a custom date field that 'is emtpy' . How can I do this please?
Thanks
A workaround is to use triggers to tag tickets (or maybe use a checkbox) if the date field has a value. Triggers have conditions to check if a date field is 'Present' or 'Not present', so you can utilize triggers to automate the process of tagging your tickets. You can then reference the tags in the condition statements of your automation.
Is there a way to create automation or a trigger that will deal with the following scenario?
A custom date field is added to the ticket form. If a date is set in that field, I want the automation to reopen the ticket on that date.
I couldn't find a way around it just yet
Gabriel Manlapig, is it possible to use "is within next" and put 0, so the automation is started on the same day as the date of the condition? Thank you
Hello,
Adding 0 in an automation doesn't work, you need to put at least 1. I have created an automation with the condition "date is within the next 1 day" and it fires a day before the date you set in the field. I was able to reopen tickets in this way and my team is using it for almost a year with no complains. They know the need to add +1 to the real date they want to reopen the ticket at.
Regards,
对我来说oposite工作,我把“机票日期" is within previous 365, and it activates on the same date as the date set in the field.
Are "Hours since..." cumulative or do they only apply for the current instance a ticket is in a particular status. E.g., Does "Hours since pending" calculate the ENTIRE amount of time a ticket spends in pending across its life? Or only the most recent status change?
I'm using two automations where the second is contingent upon actions executed by the first:
Should Automation 2 be set to "hours since pending > 20" (time spent in pending after latest status change) or "hours since pending > 60" (total time spent in pending for life of ticket)?
Thanks!
Does theHours Since Assignee Updatecondition refer to:
If the former, then will the automation run if a ticket goes from being assigned to a group to being assigned to an agent within that group? IE Assignee: Tier 1 → Assignee: Tier 1/Greg Smith?
Pleasesign into leave a comment.