This article will describe the different conditions and actions available when creating automations. For information on creating new automations, see Creating and managing automations for time-based events.
This articles 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
- Hours until next SLA breach
Note the following restrictions when using time-based conditions:
- Time-based conditions aren't available from Meet any of these conditions section of the automation creator (see Creating and managing automations for time-based events). Automations require a nullifying condition to ensure that they aren't running continuously.
- Due date refers to 12pm in your accounts 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 as Hours since open, only fire if the ticket remains in that status. For instance, if you create an automation that fires when Hours since open is 2, it will not fire if the status changes from open to pending before the two hours are up.
- Hours since update means that any update to the ticket – including an automation firing – will update the ticket.
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 a specific form. |
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: 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 the Contains at least one of the following or Contains none of the following operators, 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". |
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, see About Zendesk Support channels. For a list of the available ticket channels, see How are ticket channels defined across Zendesk? |
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. 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 your incoming support email to Zendesk or the condition won't work. |
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. |
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. If all of your conditions are true then invoke these actions to update the ticket and optionally send notifications.
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. |
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 on the ticket update. This action is available when you enable CCs on tickets.. |
Ticket: Custom fields | Custom ticket fields are available as actions. You cannot use custom fields to nullify conditions. |
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. |
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. |
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. You cannot use custom fields to nullify conditions. |
Organization: Custom fields | Custom organization fields are available as actions. You cannot use custom fields to nullify conditions. |
10 Comments
Is it possible to create an Automation Action that deletes tickets suspended because "Detected as Spam"?
Hi Pierre,
There's no way to set up an automation to apply to suspended tickets since technically the ticket is not generated until it's been recovered.
That being said, tickets should automatically be deleted from the suspended ticket view 14 days after it's originated. More information in the following article: Understanding and managing suspended tickets and spam
Hope this helps!
Is "Hours since assigned" a measure of the time since the ticket was assigned to *anyone* (the first assignment), or the hours since the *most recent* assignment, as in cases where a ticket is re-assigned multiple times?
Hi Ben,
Hours since assigned will look at the most recent ticket assignment. This will account for multiple ticket assignments if necessary.
If you run into any issues let us know and we can take a look for you.
Cheers!
In the automation hours since open will this apply to hours since the latest open status or in general since the ticket has been received (so a sum of all open hours or just the last change in status)?
As an example -
Is this how the Hours Since Open Works? This is how I've set it up below:
I just wasn't sure and want to make sure the notifications going out are correct!
Thanks all!
Hi Tamara,
The last time I tested something like this, it was total hours since open, not hours since the last time it was set to open. Therefore, I put in different conditions like hours since last update and status = Open.
As with anything, test it and then test it again!
Hi Heather,
That was exactly what I was fearing. To me it makes no sense to measure total open time but had a feeling it wasn't working properly since I received too many notifications :/
My problem with that is that we might have replied to the customer, but have not actually closed down their enquiry (e.g. sending them a holding email or similar) which is why I specifically wanted to measure the hours the ticket remained open (in it's latest state not since the moment it has been received), rather than the latest update (I already have a latest update reminder but it is much shorter, as we are obligated to reply even if it's just to say we are working on it).
Any thoughts on how to go about that?
Best,
Tamara
Hi Tamara,
I totally get it. I'd use hours since requester update then!
Hi,
"Due date refers to 12pm in your accounts timezone."
Is that 12 noon or 12 midnight?
Thanks
Hi Jose,
That's noon for your timezone, midnight would be listed as 12am.
Cheers,
Please sign in to leave a comment.