About automations and how they work Follow

all plans

Automations are similar to triggers because both define conditions and actions that modify ticket properties and optionally send email notifications to customers and agents. Where they differ is that automations execute when a time event occurs after a ticket property was set or updated, rather than immediately after a ticket is created or updated.

All automations run once every hour on all non-closed tickets. They execute, or fire, on all tickets where conditions are met.

Note: On Essential you have one default automation. On Team, Professional, and Enterprise you have a set of predefined default automations and you can create custom automations.

For information about creating and managing automations, see Streamlining workflow with time-based events and automations. For a list of default automations, The Support default automations.

Essential facts for automations

We've distilled some essential facts for you about automations. These are explained in greater detail in this article.
  • Automations are time-based; they take action when a time-event occurs, not immediately after a ticket is created or updated.

  • Automations run every hour, but not necessarily top-of-the-hour; they will start at some point during the hour.

  • Your automations will always start running at the same time every hour.

  • Automations do not run or fire on closed tickets.

  • An automation must contain a condition that is true only once or an action that nullifies at least one of the conditions; otherwise, the automation will run in an endless loop.

About automations

Automations help you manage your workflow and, potentially, improve performance and customer satisfaction by alerting you to tickets that remain unresolved and need to be escalated (for example).

Here are some uses for automations:
  • Notifying agents when an assigned ticket remains unresolved for x number of hours
  • Notifying agent groups when a new ticket remains unassigned for x number of hours
  • Notifying the assigned agent after x number of hours when a pending ticket has been updated by the requester
  • Closing tickets x number of days after they have been set to solved
  • Finding "abandoned" tickets that haven't been updated for a certain number of days
  • Sending a delayed notification for ticket comments added outside of your business hours (using a trigger with an automation; see Setting up a time delayed comment)
  • Sending an SMS text message when an urgent ticket has been unattended for more than 48 hours (using a target with an automation; see Using targets in automations and triggers)

Zendesk provides an automation that demonstrates one of these common uses:

This automation closes tickets 96 hours after they have been solved (96 hours is a support best practice for the minimum amount of time a ticket should remain in the solved state before it is closed). When the automation runs, any tickets that meet these criteria are closed. The close action looks like this:

Once a ticket is closed, it can't be modified anymore and automations no longer affect it.

This example also illustrates an important rule of automations: an automation must contain an action that cancels a condition. The ‘Status equals Solved’ condition is canceled by the ‘Status equals Closed’ action. If there were no canceling action, the automation would continue to fire in an endless loop because the status would remain solved (not closed) and continue to meet the condition criteria.

Ensuring your automation only runs once

Automations check every hour to see if their conditions are met. So an automation must include one of the following:

  • an action that nullifies at least one of the conditions, or
  • a condition than can be true only once

If there is no nullifying action or true-only-once condition, the unmodified conditions will continue to be met and the automation will continue to fire in an endless loop.

An example of a condition that is commonly nullified is a "ticket priority" condition. A ticket priority condition is usually paired with a "hours since created" condition. For example, if the ticket priority is Normal (Ticket: Priority > Is > Normal), the condition is nullified by including an action that changes the priority to High (Ticket: Priority > High) or some other priority.

An example of a condition that can only be true once is the "hours since open is" condition. This condition doesn't require a nullifying action. For example, if the hours since the ticket is open is 4 hours (Ticket: Hours since created > Is > 4), then the condition will only be true on one check. On the next check, the hours since open will be 5, and the condition will be false.

An easy way to cancel a condition is to add a tag. The automation would check for a tag and, if not present, the automation would add the tag to the ticket and perform any actions (such as, sending a notification). If the tag is present on the ticket, the automation will not perform the action again.

Understanding when automations run

All automations run once every hour on all non-closed tickets to see if conditions are met. They execute, or fire, on tickets where conditions are met.
Note: Tickets that are not closed but have had more than 100 events occur during the life of the ticket are excluded from the hourly automations run. To view events for a ticket, see Viewing a ticket's audit trail.

Your automations run every hour, but that does not necessarily mean top-of-the-hour. Your automations will start running at some point during the hour, maybe five minutes after the hour or thirty-eight minutes after the hour, for example. Your automations will always start at the same time each hour.

Although your automations start at the same time each hour, they might not fire until much later. The entire time it takes your automations to run and execute depends on how many automations and tickets there are to process. Automations run again one hour after the start time (not one hour after they finish running).

Understanding when automations fire

Automations run in order every hour and fire on tickets where conditions are met. Each automation fires—that is, takes action on a ticket—when the automation runs and conditions are met. That means the ticket is being updated each time an automation fires during the cycle, so not all automations see the ticket in the same state. The actions of one automation can affect another automation in the same hour.

Consider you have three automations:
  • Automation #1: If status is Pending greater than 48 hours, notify Assignee.
  • Automation #2: If status is Pending greater than 48 hours, change priority to High.
  • Automation #3: If priority is High, notify Escalation group.

Automations run and fire (if conditions are met) in order. So, if you have a ticket that has been pending for 48 hours, when automations run in the 49th hour, Automation #1 runs and fires, then #2 runs and fires. After Automation #2 fires, the ticket is updated to High priority. This means that when Automation #3 runs, the condition is met, so Automation #3 will fire.

As mentioned previously, automations, unlike triggers, do not execute an action immediately after a ticket satisfies the conditions. And automations do not execute exactly one hour after conditions are met. For automations, ticket updates depend on when your automations run each hour. When an automation runs it will either update a ticket or start the clock for a time-based condition ("Hours since update" for example).
  • Let's consider an example where the action will happen when the automation runs. Suppose a ticket update at 10:15am satisfies the conditions for an automation to send an email notification. If your automations run at 11:10, then the notification will not be sent until 55 minutes after the conditions are met. If your automations, however, run at 10:20, then the notification will be sent 5 minutes after the conditions are met.
  • Let's look at example with a time-based "Hours since" condition. Time-based conditions have to be satisfied within a window of time or after a minimum amount of time has passed. The first time an automation runs after an event occurs counts as "zero" hours since that event happened (because it's less than one whole hour). Suppose you have an automation that performs an action two hours after the ticket is solved and the ticket is solved at 9:15am. Here's what will happen:
    1. If your automations run at 10:10am, the ticket has been solved for only 55 minutes and the automation will not fire.
    2. Automations run again at 11:10am, the ticket has been solved 1 hour and 55 minutes, which the automation counts as one hour (because it is less than two hours).
    3. Automations run again at 12:10am, the ticket has been solved 2 hours and 55 minutes, which the automation counts as two hours. This means the condition is met and the automation will fire and update the ticket.
Note: You can see when an automation fired for a ticket by viewing the events for that ticket. For more information, see Viewing a ticket's audit trail.
Have more questions? Submit a request

Comments

  • 0

    is there a way to change the hourly automations? i used have something like that in my previous CRM, that allowed me to run an automation every night about neglected cases (last update was 96 hours ago), and send an email to the assignee about it.
    now it appears i can't do it on Zendesk since you run every hour. are there any plans to allow the users to modify the time?

  • 0

    I very much doubt ZD will be changing the hourly automation cycle simply because of the way automations work and the load this would then create. However do you really need these emails to only go out at night? If it's been 96 hours then would it matter if you sent the email during the day? You can specify how many hours since the last update in the automation.

  • 0

    Hi.. I've create automation with condition below, perhaps anyone can help me to find the root cause.

    Ticket status: is On-Hold
    Ticket: Hours since On-Hold (bussiness) is 24

    Performs: Send Email to Requester

    Ticket condition: Open -> On-Hold -> Open -> On-Hold

    Quick look on the result, 24 hours calculation On-Hold is counting from the 1st On-Hold, while I need from the last On-Hold status.
    Anyone can help me on this?

    Thanks,

  • 0

    Hi, I have seen this also. The problem is in the way automations work. As noted in this document all the changes are combined together so if you have automations that change the status then change it back then the net effect is no change and hence no change will occur. If no change has occurred then the last changed date will not update.

    I tried to be clever and use a trigger to change it back but that does not work either.

  • 0

    Hi Colin,

    Thanks for your information, the status changed because of customer reply to my update which every time I send update to Customer, I set my ticket status to On-Hold. This is why the ticket become Open then On-Hold again.
    I need inputs on how to set the best setup fro this automation.

  • 0

    Hi. So if a customer replies to a ticket that is on hold, you want to change the status back to being on hold? Correct? If so then a trigger may be better. Please confirm and I will help further. Thanks

  • 0

    Hi Colin,
    It's the other way around.
    If I sent an answer to Customer question, the ticket is set to "OnHold". This email also asking whether the information I sent is answering customer's question. After this step, it will have 2 possibilities:
    1. Customer Replied: The ticket will back to "Open" again & if I need to answer again, it will goes to "OnHold" again.
    2. No respond from Customer: This where I want automation work, from the last "OnHold", if 24Hours no respond from Requester, it will set to sent e-mail reminder that ticket will be closed in next 24Hours.
    I hope you can help me out here :)
    Thanks,

  • 0

    Ok, so this seems simple. Does this work for you?


    Meet all of the following conditions:
    Ticket: Status Is On-hold
    Ticket: Hours since on-hold (calendar) Is 24

    Perform these actions:
    Notifications: Email user (requester)
    Ticket: Add tags sent_warning


    This will send the reminder after 24 hours. It will also set a tag so you can then add a second automation but this time set for 48 hours.


    Meet all of the following conditions:
    Ticket: Status Is On-hold
    Ticket: Hours since on-hold (calendar) Is 48
    Ticket: Tags Contains at least one of the following sent_warning

    Perform these actions:
    Ticket: Status Closed
    Ticket: Remove tags sent_warning


    How's that?

    Edited by Colin Piper
  • 0

    Hi Colin,
    Thanks for the advise.

    I've set the codition same like you,

    Ticket: Status Is On-hold
    Ticket: Hours since on-hold (calendar) Is 24
    Perform these actions:
    Notifications: Email user (requester)

    Ticket: Add tags sent_warning

    If condition like this:
    Day-1. Ticket "Open"
    Day-2. I reply, "OnHold"
    Day-3. Customer Reply - "Open"
    Day-4. I reply back, "On-Hold"
    .
    Will the automation calculate from "OnHold" in Day-4 or from Day-1?
    Because previously, when I run a test, it was calculated from Day-1, causing ticket which On-Hold in Day 4 is also get reminder letter.

    Regards,

  • 0

    It should be Day-4. If this is not the case then the reason will be in the ticket audit which unfortunately I will not be able to see.

    @Jessie -- if you are listening -- if we get a domain and ticket number can you take a look at the audit for this ticket to see what actually happened.?

Please sign in to leave a comment.

Powered by Zendesk