Forums/Documentation/Managing your support workflow

Streamlining workflow with time-based events and automations

Anton de Young
posted this on April 07, 2011 08:49

Automations are similar to triggers (see Streamlining workflow with ticket updates and triggers) because both define conditions and actions that modify ticket properties and optionally send email notifications to customers and the support staff. 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.

Only administrators can create and manage automations.

For an overview of automations, see About automations and how they work.

Topics covered in this article:

Creating automations

Administrators can create automations from scratch, as shown here, or create copies of existing automations and then modify and use them for some other purpose (see Editing and cloning automations).

To add an automation
  1. Click the Admin icon () in the sidebar, then select Automations.
    Zendesk Classic: Select the Manage menu, then select Automations.
  2. Select Add Automation.
  3. Enter a title for your automation.
  4. Add the conditions and actions for your automation.

    An automation is made up of three parts, described below:

  5. You can test your automation by previewing the tickets that match the conditions that you have specified by selecting Preview match for the conditions.

    Note: The automation will have no effect on any closed ticket listed in your preview.

  6. Save your new trigger by clicking Add Automation.

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 opened

  • 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)

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.

Note: The maximum value for time-based conditions is 672 hours or 28 days. If you enter a value greater than 672 hours, your condition will not work.

The other conditions you can use in your automations are described in the following table.
Table 1. Automation conditions
ConditionDescription
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 the 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 to specify a range of tickets based on their status. For example, a condition statement that returns only New, Open, and Pending tickets looks like this:

Status is less than Solved
Ticket: Form Your ticket forms are available as conditions. Select a specific form.

See Creating ticket forms to support multiple request types (Enterprise).

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:

  • (—) indicates that no group is assigned to the ticket.
  • Group name is the actual name of the group that is assigned to the ticket.

Additional value for views:

  • (current user's group) is all the groups that the agent belongs to.
Ticket: Assignee

The assignee values are:

  • (—) indicates that the ticket is unassigned.
  • (requester) is the ticket requester. You can select this option to return tickets that were opened by and then assigned to the same agent, for example.
  • (assignee) is the person who is assigned to the ticket.
  • Agent name is the actual name of the person assigned to the ticket.

Additional value for triggers and views:

  • (current user) is the last person to have updated the ticket, which is not necessarily the same person who is assigned to the ticket. The current user (whoever updated the ticket last) changes whenever the ticket is updated. And an update may have been made by the assignee, the requester, or someone who was CC'd on the ticket.
Ticket: Requester

The requester values are:

  • (assignee) is the person assigned to the ticket. The condition statement ‘Requester is Assignee’ is true if the requester is also the person assigned to the ticket. This is possible if an agent created a ticket and was then assigned to it.
  • Agent name is the actual name of the agent.

Additional value for triggers and views:

  • (current user) is the last person who updated the ticket.
Ticket: Organization

The organization values are:

  • (—) is used to indicate that no organization has been added to the ticket.
  • Organization name is the name of an organization.
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 entered. They must be separated with a space.

Ticket: Description The description is the first comment in the ticket.
Ticket: Channel

The ticket channel is where and how the ticket was created and can be any of the following:

  • Web form

  • Email

  • Chat

  • Twitter

  • Twitter DM (direct message)

  • Twitter Favorite

  • Voicemail

  • Phone call (incoming)

  • Phone call (outgoing)

  • Get Satisfaction

  • Feedback Tab

  • Web service (API)

  • Trigger or automation

  • Forum topic

  • Closed ticket

  • Ticket sharing

  • Facebook post

  • Facebook private message

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 Using an external email domain or the condition won't work.

Ticket: Satisfaction Ticket satisfaction rating is available to Regular, Plus, and Enterprise plans. This condition returns the following customer satisfaction rating values:
  • Unoffered means that the survey has not previously been sent
  • Offered means that the survey has already been sent
  • Bad means that the ticket has received a negative rating
  • Bad with comment means that the ticket has received a negative rating with a comment
  • Good means that the ticket has received a positive rating
  • Good with comment means that the ticket has received a positive rating with a comment
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.
Organization; Custom fields Custom organization fields are available as conditions.

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.

Table 2. Automation actions
ActionDescription
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. 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 Your ticket forms are available as actions. Select a specific form.

See Creating ticket forms to support multiple request types (Enterprise).

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:

  • (—) is used to unassign a group (if one has already been assigned)
  • Group name is the actual name of the group that is assigned to the ticket.

Additional value for macros:

  • (current user’s groups) is all the groups to which the agent who is updating the ticket belongs.
Ticket: Assignee

You can set the assignee to any of the following:

  • (—) is used to set assignee to no one (unassigned)
  • (requester) is the ticket requester. You can select this option to return tickets that were opened by and then assigned to the same agent, for example.
  • Agent name is the agent to be assigned the ticket.

Additional value for triggers and macros:

  • (current user) is the last person to have updated the ticket, which is not necessarily the same person who is assigned to the ticket. The current user (whoever updated the ticket last) changes whenever the ticket is updated.
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 replaces the current tags. 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 end-user to copy on the ticket update. This action is available when you enable CCs on tickets..
Ticket: Custom fields Custom ticket fields are available as actions.
Notifications: Email user

You can set the email user to any of the following:

  • (requester) is the ticket requester.
  • (assignee) is the agent assigned to the ticket.
  • Email user name is the actual registered name of the person who will receive the email.

Additional values for triggers:

  • (current user) is the last person who updated the ticket.
  • (all non-restricted agents) includes all agents that have unrestricted access to the ticket.

Adding the email user action also inserts the email subject and body.

Notifications: Email group

You can set email group to any of the following:

  • (assigned group) is a reference to the assign group.
  • Email group name is the actual name of a group.
Notifications: Notify target Set the external target to notify. For more information about using targets, see Notifying external targets.
Notifications: Tweet requester Setting this action allows you to respond to the twitter requester with a tweet.
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.

Editing and cloning automations

You can edit and clone automations. Cloning an automation creates a copy that you can modify and use for some other purpose.

To edit an automation
  1. Click the Admin icon () in the sidebar, then select Automations.
    Zendesk Classic: Select the Manage menu, then select Automations.
  2. Locate the automation you want to edit and select Edit.
  3. Modify the title, conditions, and actions as needed.
  4. Click Update Automation.

To clone an automation

You can create a copy of an existing automation to use as the basis of a new automation.
  1. Click the Admin icon () in the sidebar, then select Automations.
    Zendesk Classic: Select the Manage menu, then select Automations.
  2. Locate the automation you want to clone and select Clone. This command appears when you move your mouse over the automation in the list of automation.
  3. Enter a new name for your automation and modify the conditions and actions as needed.
  4. Click Add Automation.

Reordering your automations

You can reorder your automations, but keep in mind that the order of your automations is important because all automations run (first to last) every hour. Actions in one automation may affect the actions in another.

To reorder the list of automations
  1. Click the Admin icon () in the sidebar, then select Automations.
    Zendesk Classic: Select the Manage menu, then select Automations.
  2. Click Reorder. You’ll find this at the end of the list of active automations.
  3. Click and drag automations to new locations as needed.
  4. Click Done.

Deleting and deactivating automations

If you decide that you no longer need an automation you can either delete it or deactivate it. Deleting it of course means that it’s gone and can’t be retrieved. You can instead deactivate automations. Deactivated automations are listed in a separate table on Manage > Automations and can be reactivated if needed.

To delete an automation
  1. Click the Admin icon () in the sidebar, then select Automations.
    Zendesk Classic: Select the Manage menu, then select Automations.
  2. Locate the automation you want to delete and select Edit.
  3. Click Delete.
To deactivate/activate an automation
  1. Click the Admin icon () in the sidebar, then select Automations.
    Zendesk Classic: Select the Manage menu, then select Automations.
  2. Locate the automation you want to deactivate and select Deactivate. This command appears when you move your mouse over the automation in the list of automations. The automation is deactivated and displayed in the list of inactive automations.
  3. To reactivate the automation, select it from the list of inactive automations and select Activate.
 

Comments

User photo
Andrew Ardill
servicerocket

It is not clear from this information if fractional hours are allowed. Can I set something to happen half an hour after a ticket is created?

Also, are automations run 'on the hour' or at the time they refer to. For example, if I create a ticket at 10:47 and have an automation that is set to act 1 hour after it was created, is that automation run at 11:47 or some other time?

Furthermore, if a condition is set to trigger at exactly 1 hour after some point, at which automation run through does it return true - only if the condition is met exactly right now, the first time after it was true, or some other time?

April 19, 2011 18:53
User photo
Anton de Young
Zendesk

Thanks for the questions Andrew. First, no, you can't use fractions of an hour. All automations are run at the top of the hour in batches for all Zendesk customers. When exactly your automations run depends on how many automations and tickets there are to process. So if a ticket was updated at 10am and your automation says to do something an hour later, it might be slightly longer than that (at 11:04 or 11:10 or something like that). Automations don't run exactly x number of hours after the conditions are met. 

 

April 22, 2011 15:52
User photo
Anton de Young
Zendesk

FYI: The condition 'Ticket Source' was renamed to 'Ticket Channel'. This article was updated to reflect that. 

June 15, 2011 16:47
User photo
Dmitry Diskin
odesk

Anton, I'd like to clarify about "hours since update". Now we have:

 

-Hours since update

-Hours since requester update

-Hours since assignee update

 

We need a way to distinguish "manual update" and "automatic update". Let me explain. When a person (not assignee, and not requester) updates ticket, we can see that "Hours since update" changes. But,  "Hours since update" also changes when another automation is run and some action is performed (e.g., notification email is sent).  Therefore, we do not have a way to see when ticket was "truly" updated.

 

Do you see a workaround? Can Zendesk add "Hours since human update" field?

 

Thanks.

October 07, 2011 02:55
User photo
Aaron Pewtherer
Zendesk

@Dimitry You are correct. "Hours since update" refers to any update to the ticket, regardless if it came from a requester, an assignee or an automation. There is NO workaround from the moment, unless you tag specific tickets not to run the automation by checking for the tag first. That is a great idea though.

October 12, 2011 12:45
User photo
Dmitry Diskin
odesk

@Aaron, can you please explain how to use the workaround? And when can we expect the "Hours since human update" field?

October 12, 2011 13:12
User photo
Aaron Pewtherer
Zendesk

@Dmitry I updated my post to say there is NO workaround. To skip an automation, add the condition "Tags contain none of the following"

October 12, 2011 14:10
User photo
Dmitry Diskin
odesk

@Aaron, but we need that another automation also, for notification. Please confirm that there are no plans to add the field I mentioned. Thanks.

October 13, 2011 10:34
User photo
Aaron Pewtherer
Zendesk

@Dmitry I have heard the "update by human" or "update by any agent" as a Feature Request in our Forums, but this is not on our roadmap at the moment. Let our developers know by submitting a Feature Request or nominating an existing request.

October 14, 2011 11:59
User photo
Manuel Keusen

Is there a way to set an automation to "business hours" so that automated notifications aren't sent on weekend?

November 04, 2011 08:53
User photo
Jill Kaselitz
Zendesk

@Manuel Within our Plus+ and Enterprise plans you will have access to business hours which will allow you to create automations to not send notifications out during the weekend. Please let us know if you have any questions on how to create this type of automation.

November 04, 2011 09:47
User photo
Gail Flynn
meteorcomm

Is it possible to create an automation or trigger to run daily against a ticket that does not receive any changes? We are interested in having - for tickets set to Pending - emails sent to the ticket requestor every 1 day.

December 07, 2011 16:04
User photo
Aaron Pewtherer
Zendesk

@Gail You can create a separate automation for each 24 hour period. (ie: Hours since Pending (calendar) 24; 48; 72. . . Perform Action: email requester) Triggers would not work in your case since they are event based; Automations are time based.

December 07, 2011 16:18
User photo
Gail Flynn
meteorcomm

Thanks - that's too bad, but now I know!

December 07, 2011 16:21
User photo
Aaron Pewtherer
Zendesk

@Gail I misunderstood your question. You want this to run indefinitely? In that case, you will need to 2 automations. The first automation would be add a tag & email requester; and the second would remove the tag if no response from enduser after 23 hours.

Automation 1:
- Conditions:
1) Hours since update greater than (calendar) 24 hours
2) Status is Pending
3) Tag does not contain notify_pending
- Action
1) Email requester
2) add tag notify_pending

Automation 2:
- Conditions
1) Hours since update is 23 hours
2) Status is Pending
3) Tag contains notify_pending
 - Actions
1) Remove tags notify_pending 

December 07, 2011 16:52
User photo
Lorraine Joubert
clickatell

Hi

 

Is there absolutely no way to have a notification sent from Zendesk if a specific action/event has not taken place on a ticket in for instance 15 minutes?

 

Regards,

Lorraine

February 08, 2012 04:36
User photo
Aaron Pewtherer
Zendesk

@Loraine Automations run hourly. This is reduce overall server usage for better balance and performance.

February 08, 2012 09:02
User photo
Matthew Pull
Foehn

Couple of things that I think need adding for Automatons / Triggers:

1. Ticket Last updated by Agent / User

This will allow us to constantly nag whoever is not updating their ticket, whether that be the agent or the requester.

2. Current Time is / is not during Business Hours (the hour the trigger/automaton is running at)

This will allow these 'nags' to be sent or not depending on whether it is business hours. Currently this is not possible.

February 13, 2012 03:55
User photo
Lorraine Joubert
clickatell

@Aaron... this is extremely disappointing, as the automations we have are very few but very crutial regarding fractions of an hour and for the automations to run as soon as or as close as possible to the time limit set within the automation.  Is there absolutely no workaround for this?  This is extremely crutial to the correct functioning of our support process.

February 20, 2012 02:17
User photo
Aaron Pewtherer
Zendesk

@Lorraine Thank you for the feedback. Feel free to add your voice to a similar feature request: https://support.zendesk.com/entries/101460-ability-to-allow-automat...

February 21, 2012 11:23
User photo
Ong Jiin Joo

Is it possible to build an automation against an agent (or a collection of tickets handled by the same agentr) instead of just on a per ticket basis? I have a number of cases I need to implement, but the most critical one is I need to be able to detect a spike and mass inform a crisis management team.

So the rule I need is something like: If more than 10 tickets are created within 1 minute against agent X, send email. Or if automations is restricted to an hour then something like: If more than 100 tickets are created within 1 hour for all agents, send email.

April 19, 2012 23:25
User photo
Nick Franklin
Zendesk

Hi Jiin Joo,

This isn't possible out of the box with Zendesk as you can't have automation that count the number of tickets and fire off that - although this a good candidate for our feature requests forum. 

If the tickets are coming in via email there may be some way to do a burst alert using your mail server settings - or an add-on.

By 'against an agent' do you mean assigned to that agent?  Does this mean you are concerned with agents having too many assigned tickets rather than there being too many tickets coming into your helpdesk?

Best regards,

Nick

April 20, 2012 02:08
User photo
Alan Bradshaw

We want to prompt customers to update tickets which have been "Pending" for a X days. Presumably at it's simplest this automation will send an email every hour which would be most annoying. If we add an action to set Status to Pending, will this be ignored (as unchanged) or will it update the tickets' timestamp so that they won't be picked up again until X days later?

I suppose we could also do this by adding a tag and first checking this tag is not already added; but then we would also need to create a few automations to check for various even older times.

April 26, 2012 03:50
User photo
Aaron Pewtherer
Zendesk

@Alan You are correct. You will need an action to nullify a condition for an automation not to send out an email every hour. This would involve 2 automations; 1 that checks for a tag, that adds a tag, then a 2nd automation to remove the tag after a certain amount of time so the previous automation would run again.

April 26, 2012 08:19
User photo
Stephen Lopez

We'd like to see an automation that would allow tickets to be generated/assigned/categorized based on the email address of the submitter.

For instance, server1@mail.edu sends a failure alert to our helpdesk inbox. Zendesk accepts the message, creates a new ticket, assigns it to AgentX, and categorizes it as Server > Fault.

Point me in the right direction if I'm just missing it, but I don't seem to be able to configure this.

May 02, 2012 16:50
User photo
Aaron Pewtherer
Zendesk

@Stephen Easily done. 

First, you would need to identify that the email is about a server fault. If the email address is always referring to a "Server Fault" then, you would add that email to an organization (ie: org, "Server Fault"), or in the enduser profile, add the tag "server_fault." (Make sure if you have enduser tags enabled under Settings > Endusers > [enable] "Tags on users")

Second, (optional) create a custom drop-down ticket field called, "Category" with the Field "Server Fault" (or Server::Fault if you are creating a nested field where "Fault" is a subcategory of server).

When a ticket is created by an enduser in the "Server Fault" organization (or has the server_fault tag), create a trigger that reads, 1) Ticket is created, 2) Org is...Server Fault/Tag contains...server_fault; Action: Assignee...AgentX; (optional: Category...Server/Fault).

With the ticket tagged, you can run reports based on that tag or dropdown.

May 03, 2012 09:00
User photo
Stephen Lopez

@Aaron Thank you. It was so simple that I just over-thought it. The tagging option never even crossed my mind. I just tested it and it works perfect.

May 03, 2012 10:34
User photo
Rob Dziadosz

Having a bit of difficulty in creating an automation where it alerts the Asignee (agent) that the case has not been updated in X amount of hours. Maybe I'm missing something simple ..

August 02, 2012 12:19
User photo
Aaron Pewtherer
Zendesk

@Rob: Try using Condition (ALL): "Hours since updated is .... X"; Action: Email User > Assignee.

August 02, 2012 12:39
User photo
Alan Jiménez

I'm unclear as to when "Hours since open" means.

If a ticket is in pending status, and the requester answers back so that the issue goes back to open, does this count as "Hours since opened"? Would it then start counting from zero, or does it accumulate from "open" statuses prior to the occurrence?

I'd suggest you further specify the meanings and behaviours of these conditions.

September 24, 2012 02:14
User photo
Aaron Pewtherer
Zendesk

@Alan: Here are the official definitions:

1. "Hours since open": Combined total time spent in New and Open statuses; if ticket is re-opened after being solved, time spent in Solved status is counted as well. Time after final change to Solved status is not included.
2. "Hours since pending": Total time spent in Pending status.

September 25, 2012 14:37
User photo
Johanne Leveille-Schirm
karoshealth

I am trying to set an automation that would send an email to the agent (aka assignee) after X amount of hours if he/she has not updated the ticket but the only actions I am seeing is "email group". Am I missing something?

I am also trying to do the same thing if the requester has not updated to ticket in X amount of hours - I just want the assignee to be notified.

Am I missing something?

September 26, 2012 09:37
User photo
Aaron Pewtherer
Zendesk

@Jschirm: Use the condition, "email user...assignee."

September 26, 2012 09:43
User photo
Brooke

Hey y'all -- Is there any way to automate the actual updating of tickets with comments?  I know I can switch to "event view" when looking at a ticket and see, for example if a trigger email went out, but my agents can't see what  the email said, which can be really confusing.

October 08, 2012 16:54
User photo
Brooke

Also, whereas in "classic" Zendesk, it seems you can tap the event number when in the event view to see the text of the trigger email that went out, no such tap-able event link appears in the Lotus ticket event view.  Am I missing something, or did you abandon this feature?

October 08, 2012 17:25
User photo
Jeffrey Herr

+1 for adding a comment.  I'd like to add "Escalated due to xxxx"

October 17, 2012 14:19
User photo
Aaron Pewtherer
Zendesk

@Brooke: The template for email notifications are not in the New Zendesk yet.

@Jeffrey: Allow you cannot add a comment as an automation; you can change other ticket properties, and perhaps email agents on ticket updates.

October 19, 2012 14:58
User photo
Will
Forever New

Hi guys,

I'm trying to set up a automation that has the following rules.

If the last comment is by the assignee, and the hours since comment is greater than X.

We want to send a comment to the requester that they have not replied to our ticket update.

Is this possible?

Thanks guys

November 01, 2012 00:26
User photo
Aaron Pewtherer
Zendesk

@Will: Ah! That's a tricky one, but theoretically possible. As you may have noticed, in an Automation, there is a "hours since assignee update" condition. This would probably work for most of your scenarios. However, an "assignee update" could be anything, from merely changing a ticket property to adding a comment.

Would you like to be more specific? Just last comment? In that case, the agent would need to change the ticket status to "pending". Then use, "hours since pending." This may require that the agent toggle the status back and forth (update ticket twice) to restart the Pending clock.

How_to_Automation.jpg

Let us know more about your workflow. Unfortunately, there is no condition for "hours since last assignee comment" available. Add that to the Feature Request forums fo alert our developers. :)

November 01, 2012 09:03
User photo
Will
Forever New

Hi Aaron,

Thanks for your input. Let me give you a bit of background. We have a large number of helpdesk fast moving tickets which we need to keep track of. We've had a few scenarios where we are awaiting for the requester to come back to us with further information.

Now is it possible to send a reminder to the requester/assignee to chase this up (or even auto solve the ticket)?

I've seen hours since assignee update but how (if possible) can we determine if the last comment is by the assignee and not the requester?

Thanks for your time Aaron.

 

Will

November 01, 2012 15:49
User photo
Aaron Pewtherer
Zendesk

@Will. Hmm. Yeah, no way in an automation to determine if the last comment update was from the agent or requester, only whom made the last update (by time).

There is an option in the trigger of, "Current user.... requester/agent" & "Comment is...present" to add a tag (see below). Then, use the "hours since update" as the condition, and look for the tag.

Note: You would probably want to clone the suggested trigger conversely. Meaning, if the requester does the update, remove the old tag, replace with new tag, and vice versa.


Agent_tag.jpg

November 01, 2012 16:26
User photo
Mike Ryan

Hi. We've been adhering to the "Close ticket 96 hours after status is set to solved" best practice. But, now, due to some of our clients' continually adding onto what we deem Solved issues, we're having a hard time preventing clients from understanding that, "Yes, the issue you sent us is closed - but, now you're asking us about a new issue -- and that should be requested as a new issue." So, I've been asked to shorten the window between Solved and Closed, but I am not sure this would be ideal. Is there anything that I should be concerned about (that I'm not thinking of) were I to shorten the 96-hour window to, say, 8 hours? I can't think of anything....Thoughts? Suggestions?

Thanks!!

January 29, 2013 08:04
User photo
Jennifer Rowe
Zendesk

Hi Mike,

It might be a good idea to post this question in our Community Q&A forum! More people might see it there and offer some advice.

January 29, 2013 14:03
User photo
Hugo Tobias

Hi there,

When setting up automations I noticed that they run at the top of the hour. We are looking to setup an automation that will notify us when a ticket has not been assigned to a user within 1 hour. When we tried to set this up, we noticed there was an issue in that when the automation ran (on the hour), if the ticket had still not passed the hour mark, we would have to wait until the next hour for the automation to run again. This means we sometimes would only get the notification at up to 2 hours.

What development is currently going on regarding this as it would be extremely important for our SLAs and would need the automations to run much more frequently.

February 28, 2013 08:57
User photo
Firas Naji

Hello,

I'm trying to set up a trigger based on the contents of comments.  The trick is the comments are pulled from our DB using the API and are private.  I've tried bunch of different variations using the options selected, but the trigger isn't working.  Here's the basic idea of what I'm trying to do:

MUSTS:
Comment text contains the following string: XXXX XXXX XXXXX
Status is Less than Solved
Assignee is: SOandSO

Perform these actions:
Status: Solved

Looks pretty straightforward, but it's not working.  I've tried updated some tickets to see if the trigger will take effect, but it didn't work.  The comment I'm using is a private comment.  The only issue I can think of is because the comment I'm looking for has a colon, which effect how the trigger searches.

Please help

Thanks! 

April 24, 2013 14:54
User photo
Aaron Pewtherer
Zendesk

@Hugo: Development is working on options for automations that run more often, most likely as an add-on feature. At the moment, since all accounts are on shared servers, automations run once an hour for overall optimization. Stay tuned to our Announcements forum for product releases.

@Firas: Seems fine. Click the "events" link inside a ticket to see if another trigger is running afterwards. Send a ticket into Support if you would like to review. Include an example ticket number, subdomain, and name of trigger.

April 30, 2013 16:36
User photo
Tisha Levy

I am trying to an automation for Status = Pending and when it is in pending status longer than 5 business days it send email and sets status to "solved".  This worked once, but is now no longer working.How should this be configured?  When I hit "preview matches for this configuration", it shows no matches which I know is not accurate.  Any input is appreciated.

August 05, 2013 11:32
User photo
Tisha Levy

Disregard my previous comment. When it was set to business greater than, it did not work.  Setting it to "calendar" greater than it did.

August 05, 2013 12:08
User photo
Jennifer Rowe
Zendesk

Awesome, Tisha! Glad you figured it out.

August 05, 2013 13:19
User photo
Jacquie Hauth

Hey guys! Just a clarification request:

Hours since pending ... is this total hours pending (say, if a ticket jumps between open and pending a few times, does this add up the total hours pending), or is this the hours in pending during a current pending stage (say, if a ticket has jumped statuses a few times and is now in pending, does this add up only the hours spent since the ticket was last placed in a pending state)?

Thanks!

August 08, 2013 07:04
User photo
Laura D.
Zendesk

Hi Jacquie, 

Good question! It's the current pending stage - if it's been in pending before that time doesn't count. You can think of it like "Time since ticket's status was changed to pending" if that helps. Hope that helps!

August 08, 2013 11:46
User photo
Andy Rose

I also have a need to see a count of tickets matching a set of rules. We receive emails from external monitors that are not very important unless they show up in a cluster. Our rule is that if we receive 10 of these messages within an hour, it will escalate the issue. We have no control over how these monitors are executing, but they do contain valuable information. 

This functionality seems like something that should be packaged with your service and I am surprised that its not. In any case, it will be a lot easier for Zendesk to add this capability to the "Automation" system than it will be for my team to create an entire service that constantly watches the mail server.  

I will go ahead and submit this as a feature request. Do you have any feedback on how long this will take to get through the Zendesk roadmap? Having a timetable will help prioritize the creation of our own workaround. 

August 15, 2013 13:42
User photo
David Greig

Early in this document there is a statement “All automations are run at the top of the hour in batches for all Zendesk customers”. This is followed several sentences later by “The order of your automations is important as well because all automations run (first to last) every hour.” Later, under the heading “REORDERING YOUR AUTOMATIONS” the statement is repeated as “You can reorder your automations, but keep in mind that the order of your automations is important because all automations run (first to last) every hour. Actions in one automation may affect the actions in another”.

Given the emphasis on the ordering of the automations I didn’t take too much notice of the fact that the automations are run in batches. I must admit that I just assumed that the batching of tickets just meant that the order of the processing of tickets was unpredictable (i.e. the tickets were batched independently of the account or, perhaps, batched by account by where my accounts is processed in relation to other accounts is unpredictable).

Consequently I was more than a little surprised when, in answer to a ticket I raised requesting an explanation of why some test automations weren’t running as I had expected them to, I was advised that this was caused by the batching of tickets. The ticket I raised (#462543) had responses which included:-

“I have confirmed with our product team that automations run in batches and therefore they will ignore each other’s changes. This is expected behaviour.”

and

“Batches are of interest here because it is why your automations do not work as you expect them”.

Clearly this batching is not as benign as I was expecting but it is not clear to me what is happening in the batching which is impacting the running of the automations.

Could you:-

  • Explain the batching process.
  • Advise how I can anticipate (and avoid) the impact of the batching on the automations.
August 26, 2013 22:54
User photo
Laura D.
Zendesk

Hi David, 

I know you have a ticket going with us, someone will be getting in touch with you soon to provide more information, but I wanted to post here too in case other people have related questions. Also, you're right we do need some clarity about how automations work, I've already gotten in touch with our Documentation team and they are planning to address this very soon. 

Now, for some details :) 

Automations are run in batches. What's missing from this explanation is that when automations are checked against a ticket we use the same ticket state when checking all automations within a single cycle. For example: 

  • Ticket #25 exists  - let's say the ticket is open, unassigned, and has one tag.
  • The three automations exist: Automation 1 looks for a tag and adds another tag, Automation 2 looks for the tag that Automation 1 added and changes the assignee, Automation 3 looks for the assignee that was added in Automation 2 and the tag that was added in Automation 1 and increases the priority. 

So, 9am rolls around and Zendesk sees the current state of ticket #25 - one tag, no assignee, and open. It compares that definition to the three automations. Only Automation 1 has a condition that match the current state of ticket #25 (the tag is the same) - what Automation 1 does to the ticket isn't considered when checking the ticket against Automation 2, because the there is only one state for the ticket at 9am. When we say automations are run in batches we mean that they don't have a cascading effect during the same run - the system doesn't look at ticket #25, make updates according to automation 1, then take that updated definition of the ticket and then check it against Automation 2 etc. This is why we refer to Automations as time based - they look at the state of a ticket at a certain time and use that to determine what automations apply at that time. 

This is different from triggers - I'll post on your other comment there shortly. 

If you want to build a set of actions that  build on each other and are executed in succession without a break in time, then you either want to use Triggers, or a combination of an automation and triggers. For instance, in the above scenario if you want the tickets with a certain tag to be picked up, have another tag added, be reassigned, and have their priority increased after 6 hours you could do this with an automation that looks for:

  •  the conditions: "hours since updated 6" and a tag, "vip" 
  • performs these actions: adds a "vip_urgent_assistance" tag

A trigger would then look for the "vip_urgent_assistance" and change the assignee, update the priority, etc.

We'll update the docs soon, thanks for pointing out the inconsistency!

 

 

August 27, 2013 13:51
User photo
Jacquie Hauth

Thanks for following up on my previous question--could I ask for clarification on one point?

If a ticket is moved from an open to a pending status on Monday, and an agent edits the ticket on Tuesday to send a quick follow up and submits the ticket as pending, will "hours since pending" automations count time since the ticket was marked pending on Monday or Tuesday?

Thanks in advance! You guys are awesome.

August 28, 2013 06:20
User photo
David Greig

Laura,

Thank you for the clarification of the way batching works and the impact it has the conditions which are used in the automations. Unfortunately it still doesn’t answer my specific question which is, “is it possible, under any circumstances, for more than one automation to run against the one ticket in the one hour”.

My aim was to set up two automations, without any dependencies upon each other and with the simplest conditions and actions possible. Consequently the two automations each just tested for the non-existence of their unique tag and added that tag. I don’t see how your explanation of the batching process has any value in explaining why these two automations only ever run in consecutive hours. The third automation was just to remove the tags so the automation process would keep repeating and, I accept that this would be affected by batching.

Even though two automations should be enough to prove whether multiple automations can run against a single ticket in a single hour I have created an new set of automations to further test whether this is possible. The new automations (which are share a common tag “Trying_to_determine_if_multi_autos_are_possible”) are "An automation which should run", "Another automation which should run", "Yet another automation which should run", "Even this automation should run", "This one too", "and this one too" and "even this one too". Their individual tags are "none_of_these_tags_are_present", "at_the_start_of_the_automation_batching", "so_all_automations_which_test_for", "the_non_existence_of_these_tags", "should_run_if_it_is_possible", "for_more_than_one_to_run" and "in_any_one_hour" respectively.

Could you please check ticket #169 in our Sandbox and advise why these seven automation don’t all run sequentially in the first hour.

Regards,

David.

September 01, 2013 23:10
User photo
Brandon Conn

How can I allow the small "check box" that allows a customer to "request is solved" when a customer is commenting on the ticket?

September 02, 2013 20:59
User photo
Casem AbuLughod
Zendesk

Hi Brandon,

That button will show up as long as all of the fields (custom ticket fields and otherwise) that have been marked as Required have been filled out.

Hope this helps!

September 03, 2013 14:28
User photo
Laura D.
Zendesk

Hi David, 

Yes, more than 1 automation can change a ticket within one hour - only if the conditions it requires to change a ticket are met by the ticket at the beginning of the hour, i.e. before the other automation (or automations) changes the ticket. 

For example, if you have Automation #1 that assigns a ticket a priority and Automation #2 that assigns a tag, as long as the ticket meets the conditions conditions of Automation #2 BEFORE Automation #1 changes it (because Automation #1's changes won't impact the definition of the ticket when it's checked against Automation #2 in that hour) then both Automations will update the ticket in the same hour. 

If the condition for Automation #2 aren't met until after Automation #1 has run and updated the ticket, the changes from Automations #2 won't be applied until the following hour. 

Looking at ticket #169 the automations should have fired in the same hour because the conditions for each automation are met by the ticket's definition at the start of the run, they aren't dependent on the actions of the other automations - we'll have to dig into why they each ran an hour apart instead of together. I'll add notes to your existing ticket and once we have more information we'll update you there.  

I think we're on the same page as to what should happen with automations, and so I'd say let's return this conversation to the ticket. I'll send Documentation some notes about what would be helpful in this article.

Thanks for all the testing - I think the clarifications that came out of this will help everyone! 

September 04, 2013 14:56
User photo
Laura D.
Zendesk

Hi Jacquie,

Thanks - we're always happy to help! In that case, because the status of the ticket hasn't changed, the "hours since pending" will be counted starting from the update on Monday when the ticket was last changed to pending. Hope that helps :)

 

September 04, 2013 15:14
User photo
David Greig

Laura,

I've just learnt of another restriction to automations in a response to my help desk ticket #487006 - "we have a rule in our code that stops automations from running after there have been over 100 system interactions on a ticket". That rule might be worthwhile documenting too.

Regards,

David

September 05, 2013 21:36
User photo
Laura D.
Zendesk

Thanks David, I'll check with Documentation about adding that too. 

September 06, 2013 09:45
User photo
David Greig

Laura,

I've just been advised that a change has been made to allow multiple automations to run against a single ticket in one automation run. I have confirmed that this is now working in both the Sandbox and production environments.

Regards,

David.

 

September 22, 2013 17:49
User photo
Laura D.
Zendesk

Hi David, 

Yes I saw that - we'll work on getting the documentation for triggers and automations clarified now. Thanks for all your help and patience while we looked at everything!

September 24, 2013 16:03
User photo
David Greig

Laura,

It will be interesting to see whether you getting any complaints from customers who had built a reliance on the old situation, for example, if they had multiple SLA automation sequenced as >10, >8, etc.

I do think this change exposes the issue of the restriction on number automations can run for a given ticket. If you did want an automation to run every hour, as you would if you wanted to condition subsequent automations on whether it was inside or outside business hours, automations would stop after 4 days. Of course the need to set a tag so automations could determine whether they're operating in business hours would be easily fixed by just allowing automations to check business hours the same way as triggers can.

Anyway thanks for your help in resolving my issue.

Regards,

David.

 

September 24, 2013 16:30
User photo
Marc Greenfield

Hi,

One of the common uses for automations in your documentation is 'notifying agent groups when a new ticket remains unassigned for x number of hours.' I am new to Zendesk and this is what I am looking to do, or as close as I can come (Ideally, I'm looking to send an email to two of our Admins if any tickets are unassigned at the close of our business hours at 5:00 PM). However, when I tried to set this automation up, Zendesk said that an automation has to nullify an existing condition, which sending an email does not do. How would I implement this automation?  I tried adding a tag on the ticket (i.e. overdue), and then email our admins, but that still didn't work. Is there a simple way to do what the documentation lists?

October 01, 2013 17:36
User photo
Laura D.
Zendesk

@David - I'm not sure about issues with automations since things were fixed, we haven't seen a spike in tickets about it but we'll have to see. Thanks for the comments about the limitations of automations, I'll pass it along to the Product team. I'm glad we were able to help, I certainly learned a lot and I know it's had a positive impact on the information we provide to agents during training and will be reflected shortly in the customer facing documentation. 

 

@Marc - You're on the right track by adding a tag to the ticket when the automation runs and sends an email. The way you can use the tag as a nullifying condition would be to have the automation check for the same tag in the conditions area. This means when the automation runs for the first time it will check for the tag "overdue" not find it, and send an email and add the tag. The next hour it will check for the tag, see it's already on the ticket and not run (meaning you won't be notified again).

Regarding creating an automation to notify at a specific time like 5pm, automations don't run exactly on the hour (5pm) and they have time conditions that are about how much time has elapsed, not what time it is. For example, you can create an automation to notify agents if a ticket hasn't been updated in about 6 hours (depending on when an automation runs). Although there isn't a way to do this with Zendesk out of the box we do have partners who've built custom solutions to do this, if you want to talk about about that let me know and I can start a ticket for you. An alternative to that would be to create a view of all tickets that are unassigned, copy the URL, and make a calendar reminder with that link to remind admins to check that view at the end of the day. Clicking on the URL would prompt them to login or open the page if they are already logged in. That's not as informative as an email with ticket links but it would mean if an admin needs to take action they'd already be in the agent interface. 

October 07, 2013 10:47
User photo
Larisa Moore
RealNetworks, Inc.

Hi, I have a question about using "Is" versus "Is greater than". We want to close certain tickets if there has been no update after 10 days. Currently the automation is set to close those tickets if "Time since update is 240 hours." Since the automations run at the top of the hour, will this condition still catch tickets where it isn't *exactly* 240 hours, but maybe 240.5 hours, or 239.2 hours? We do have some tickets that don't appear to be closing when they should.

October 23, 2013 13:19
User photo
Emily
Zendesk

Hi Larissa, 

When you put "is" into an Automation, you're telling it to only fire once. Automations run every hour. Our system begins running all Automations across all Zendesks at the top of the hour, but the Automation might not run (or fire) exactly when the clock strikes 240 hours (in your example). It could run 5 minutes after that, or ten minutes after that, etc. The bottom line is: You only get one chance for the conditions to be true at 240 hours if you use "is." After the Automation has fired once (between 240 hours and 240 hours and 59 minutes), it will not fire again. 

 You can say "is greater than" to ensure that if the Automation runs during the 240th hour just before the conditions become true, it will catch them (and fire) when it runs again in the 241st hour. 

October 25, 2013 17:12
User photo
Craig B. Clawson

@Emily.  The problem here is that your suggestion is counter what the documentation says.  Above it states:

"If possible, use the "hours since open is" condition instead of the "hours since open is greater than" condition. The "greater than" condition will be true on all future checks unless you specify a nullifying action"

and there's the rub for someone who does want it to fire only once. we can't count "is" to hit right, and "greater than" will continue to run.  

Am I in the right on this?

 

October 29, 2013 15:44
User photo
Larisa Moore
RealNetworks, Inc.

Yup. If the automation doesn't change the status, then I have it add a tag to the ticket, so the automation only runs if the tag is NOT present. That way, it only runs once per ticket.

October 29, 2013 15:52
User photo
Emily
Zendesk

Hi Craig, 

I regret any confusion there may have been. Let's differentiate between "run" and "fire" (and I'll update these words in my answer above so it doesn't confuse other customers). Zendesk runs your Automations every hour, meaning we check to see if the conditions are true across all your tickets. If the conditions are true, Zendesk will fire that Automation in your ticket, which performs an action.

When you use the "is" function in an automation, you are giving the system a one hour time period during which it can fire that Automation. Yes, it is running every hour, but there is only one hour-long period when the conditions will be true and the Automation can fire.

When you use "is greater than" with a nullifying condition, you give the Automation's hourly run a larger window during which it can fire. In the latter case, once it fires, the nullifying condition will prevent it from continuing to fire every hour after that. It will still run every hour, but once it fires once, the nullifying condition will prevent it from being recurring.

If the potential for lag in the Automation's hourly run is an issue for you, there is a services package you can purchase to ensure a specific time during the hour that your business rules should always run. This is designed to ensure your SLAs are met down-to-the-minute. If this interests you, please submit a ticket to support@zendesk.com and we'll connect you with our Services Team to discuss it further.

 

October 29, 2013 16:27
User photo
Craig B. Clawson

Thanks for the clarification! 

If the back-end system accepts a partial of the hour, and don't need to run exactly at, say, 1:24 in order to qualify for the "IS" statement, then that's close enough for my purposes.

 

October 29, 2013 16:35
User photo
Maria Nørgaard
venuepoint

Is it correct that I cannot create an automation that has an "any" condition that needs to be changed? So instead I have to add an automation per "any" condition and instead set these conditions as "all" in the individual automations?

November 21, 2013 03:26
User photo
Anthony Roman
Zendesk

@Maria - It is true that you cannot nullify an "any" condition because even if you have an action that nullifies one "any" condition, there are still other "any" conditions that can make the automation run in a loop. What you can do is use tags to make sure the automation runs only once. In the "all" conditions, add a condition "tags contains none of the following some_tag", then in the action, add "add tags some_tag". This will ensure that the automation will only run once per ticket and not send out endless emails.

November 24, 2013 22:06
User photo
Erik Ehrner

Hi guys. 

I guess I'm not the only one here who's keen to see a n example of the (business) definition. Could you please show me a capture of how that looks like when you want to change a ticket from pending to solved after 3 business days?

Bonus question, if during Christmas & New Years you would like to have a different policy (since I guess Zendesk will consider all these days being working days) how would that look like? Is it by then better to customize a new automation just over Christmas & New Years that overrides the other automations?
 

November 27, 2013 08:30
User photo
Arthur Mori
Zendesk

Hi Erik,

Simply follow these conditions:

Screen_Shot_2013-12-01_at_4.23.45_PM.png

 

... with regards to having an automation during the Holidays, what exactly are your trying to achieve? You want to extend the tickets pending state because of the Holidays? If so, you can create a new automation and follow the same exact condition as mentioned in the screenshot above, but in your action just update the ticket instead of marking it as solved (a simple adding of a tag should do the trick). After creating this automation re-order it above the automation that auto-solves the ticket after 3 days to work properly. 

December 01, 2013 00:22
User photo
Chris Cogdon
instartlogicinc

We have an automation that "fires" if there has been no update on a ticket for 72 hours. The action is to send out a couple of reminder emails. This part works perfectly. However, a side effect is that the "updated" time on the ticket is reset to the current time. This isn't desirable as this re-orders the tickets in one's display and doesn't seem sensible since the only thing that was done was to send out a few emails: nothing in the ticket actually changed.

(Technically, I know this isn't true, as sending out an email adds an event to the ticket).

Is there any way to have an automation _not_ change the "Updated" attribute on the ticket.

December 05, 2013 19:25
User photo
Laura D.
Zendesk

Hi Chris,

If an automation fires on a ticket that will always count as an update.

You have a few options for working around this including:

  • changing the criteria for the view to be "Latest update by requester" or "Latest update by assignee" neither of these will include what the system does
  • changing the "Order by" criteria of the view to be requested date - or one of the other update types.

Both of these options are available on the editing page for the view - to get there click on the title of the view and then "edit" from the pop up menu or, go to Admin > Manage > Views > and choose "edit" next to the name of the view. 

Hope this helps!

December 09, 2013 10:11
User photo
Wilson Cimino

What kind of custom fields (number/dropdown/checkbox) I can use as conditions for automation? I want to trigger an event when a field is filled or not.

 

Tks!

Wilson

January 16, 2014 08:41
User photo
Emily
Zendesk

Hi Wilson, 

Your drop-down and checkbox custom fields will be available to select when building an Automation/Trigger. That's because these are the only two field types that also tag tickets, and tags can be referenced in your business rules. 

January 21, 2014 09:32
User photo
Maria Nørgaard
venuepoint

@Aaron Thank you for your reply - and sorry for getting back to this matter so much later.

In our case, there would not be another "any" condition making this automation run in a loop, as it would be more of an "either or" condition. Also, the automation does not send out an email, but changes something in the ticket fields, therefore, it would still be best solution instead of having to create 15 automations.

The specific case: I would like to make one single automation that runs in case the assigned agent is one of some specific agents (casual employees only). These employees are not in a specific group, as they need to have access to the same tickets as everyone else in the team. The automation I want to create is that these agents should be unassigned after 12 hours since the last assignee update, and thus other agents are able to reply to these tickets, in case the first agent assigned is not at work the next day. I hope this makes sense.

I have now created an automation per agent, but it would naturally be much better if I only had to crete one for all agents.

 

Best regards, Maria

February 27, 2014 02:42
User photo
Aaron Pewtherer
Zendesk

@Maria: You can nullify an automation loop with either, 1) Using an "is" statement in the "all" condition or, 2) Add an converse action that is also a condition. (e.g. Condition: Tags ... contains none of the following ... example_tag; Action: Add Tags ... example_tag)

We added an inactive automation to your account to show this. Let us know if that works.

February 27, 2014 08:27
User photo
Maria Nørgaard
venuepoint

@Aaron: I'm sorry - my comment was actually meant for @Anthony, who replied to my former post. I apologise I wrote to you instead.

I'm not looking to nullify and automation loop, but instead I wish to create an automation that has an "any" condition that needs to be changed, which Anthny wrote was not possible as it would create an automation loop. Therefore, I was simply trying to explain that this would not be the case for us.

February 27, 2014 23:47
User photo
Maria Nørgaard
venuepoint

Hmmm... I think I just gave myself the answer after re-reading my previous post. Creating an extra group for these employess would solve the issue. :)

February 28, 2014 00:00
User photo
Emily McDaniel
gainsight

We need to notify a specific user via email anytime there is a ticket with the tag paid_pilot that has not had any updates in x amount of hours. Every time there has not been an update for x amount of hours another email needs to go out as long as the ticket status is less than solved. What is the best way to do this?

April 07, 2014 14:40
User photo
Chris Cogdon
instartlogicinc

Emily,

Because having a trigger that does anything to the ticket updates that ticket time, the "obvious" solution won't work. I suggest that the first event (triggered after x hours) sends out the email, but also adds an additional tag called "paid_pilot_overdue". You create another automation that, when _this_ flag is set, sends out an email each time (which will be each hour). You should also modify the first event to _not_ send out if this flag is set. I.e., the first automation checks for "paid_pilot" is set, "paid_pilot_overdue" is _not_ set, and that there's been X hours since the last update. The action is to send out an email and add the "paid_pilot_overdue" flag.

April 07, 2014 14:50
User photo
Emily McDaniel
gainsight

Chris, 

Thanks for the quick reply! So are you saying that I would just need to have 2 automations? One which would add the second tag and the other that would remove it? 

April 08, 2014 08:47
User photo
Graeme Carmichael
nhsggc

@Emily

I think you can manage this with one automation:

Meet all the following conditions:

  • Ticket hours since update equals XX
  • Ticket status less than solved
  • Ticket tags contains at least one of the following paid_pilot

Perform these actions:

  • Notification email user

Once the automation fires, if there has not been another update for XX hours, it should fire the same email again.

If you are wanting an escalation, so that a different email needs to be fired the second time, it would be easiest with 2 automations and use additional tags as Chris has suggested.

 

April 08, 2014 09:18
User photo
Chris Cogdon
instartlogicinc

Emily: My solution assumed that after X hours an email is sent out, and then each hour after that there's another (either similar, or different) email. Because sending out the email resets the "last updated" time, using a different automation was the only way to do it.

If you simply wanted an email each X hours, then the simplest of automations would do it. Only if you wanted a different "nag" rate, or a different message, would you have to use the additional "nag tag".

The first automation sets the "nag tag". The second automation doesnt delete it, since doing so would revert back to the "alert after X hours" behaviour. You would have to have some _other_ method of removing the "nag tag". I'd recommend a trigger based on any activity by an agent.

April 09, 2014 12:44