Forums/Documentation/Managing your support workflow

Streamlining workflow with ticket updates and triggers

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

Triggers are business rules you define that run immediately after tickets are created or updated. For example, a trigger can be used to notify the customer when a ticket has been opened. Another can be created to then notify the customer when the ticket is solved. For an overview of how triggers work, see this video.

Only administrators can create and manage triggers.

Triggers contain conditions and actions. You combine these to create ‘if’ and ‘then’ statements (if the ticket contains a certain set of conditions then the actions make the desired updates to the ticket and optionally notify the requester or the support staff). You build condition and action statements using ticket properties, field operators, and the ticket property values.

There are two types of conditions – all conditions and any conditions. The all conditions, as you’ve probably already figured out, must all be true. If any of the condition statements fail (are not true), the trigger will not act on the ticket.

Additionally at least one of the any conditions must also be true. For example, you might want a trigger to act only on tickets that are submitted from a list of specific email addresses, as in this example:

If either of these conditions is true, the trigger will fire. If you use only one condition in the any section, it will behave like an all condition and therefore must be true for the trigger to fire.

Action statements follow the same format, but rather than testing for conditions to be true or not, actions set ticket properties and send email notifications, as in this example:

Each time a ticket is created or updated all of your triggers run; therefore, as you’re creating triggers you need to think about the order of triggers because an action in one trigger may change a ticket property that was changed by another trigger. If you're not careful, this can result in multiple email notifications being sent, which can create confusion for your customers.

Zendesk triggers to get you started

To help you get started with triggers, Zendesk provides you with a standard set of triggers and mail notifications that are best practices in a typical ticket workflow. You can view a list of these default triggers in the Resetting default triggers topic. To view these triggers in your Zendesk, select the Triggers page. You can select Edit to see the conditions and actions that have been defined for each trigger.

You can use these triggers as they are or clone them to make copies that you can modify and repurpose. You can also edit these triggers but it's better to clone them and make changes to the copies. You can then deactivate these Zendesk triggers if needed.

Creating triggers

You can create triggers from scratch or create copies of existing triggers and then modify and use them for some other purpose (see Editing and cloning triggers).

Community tip! Alexander Aghassipour shows how to build a trigger that auto-assigns a ticket to the first responding agent.

To add a trigger
  1. Click the Admin icon () in the sidebar, then select Triggers.
    Zendesk Classic: Select the Manage menu, then select Triggers and mail notifications.
  2. Select Add Trigger.
  3. Enter a title for your trigger.
  4. Add the conditions and actions for your trigger (described below).
  5. Save your new trigger by clicking Add Trigger.

Your new trigger is added to the end of the list of triggers. You can reorder the list of triggers. For more information, see Reordering triggers.

Community tip! Justin Graves of Ensign Facility Services shares a tip for organizing your triggers in our Community forums!

Building trigger condition statements

Condition statements consist of conditions, field operators, and condition values (these vary depending on the condition selected). Condition statements are essentially ‘if’ statements that return all tickets that meet the specified criteria. The first condition statement that evaluates to false terminates the trigger.
Table 1. Trigger 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 Ticket: Form, then 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: 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: Update via This condition indicates from where the ticket was updated and can be any of the same sources as the ticket channel condition (above).
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: Is Created or Updated.
Ticket: Comment is

This condition returns the type of comment contained in ticket updates.

Public is a comment that everyone can see.

Private is a comment that only members of the support staff can see.

Present (public or private) is used to indicate if the update contains a new comment.

Present, and requester can see the comment is used to indicate that the update contains a comment and that it is visible to the requester (in other words, not private).
Ticket: Comment text

Using this condition you can check for the presence of single words and strings of words in either the subject or body of the comment. You can use any of the following operators:

  • Contains at least one of the following words
  • Contains none of the following words
  • Contains the following string
  • Contains not the following string
Ticket Reopens (Plus and Enterprise) The number of times a ticket has moved from Solved to Open or Pending.
Ticket: Agent replies (Plus and Enterprise) The number of public agent comments.
Ticket: Assignee stations (Plus and Enterprise) The number of different agents to which a ticket has been assigned.
Ticket: Group stations (Plus and Enterprise) The number of different groups to which a ticket has been assigned.
Ticket: Within business hours? Yes or No. This condition is available if an administrator has enabled business hours.
Ticket: Custom fields Custom ticket fields are available as conditions.
Requester: Language Returns the language preference of the person who submitted the request.
Requester: Twitter followers are This is the number of the requester’s Twitter followers.
Requester: Number of tweets is This is the total number of the requester’s tweets.
Requester: Is verified by Twitter This condition is used to verify that the requester is a verified Twitter account.
Requester: Custom fields Custom user fields are available as conditions.
Organization: Custom fields Custom organization fields are available as conditions.
Current user

You can select any of the following for the type of user that last updated the ticket:

(agent) is a support staff member.

(end user) is anyone who is a registered user and not an agent or an administrator. They can only submit and track tickets and communicate with agents publicly (meaning their comments can never be private).

Agent name is the actual name of an agent.

Building trigger 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 perform these actions to update the ticket and optionally send notifications.
Table 2. Trigger 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 the current 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.

Reordering triggers

You can reorder your list of triggers. Remember that all of your active triggers run each time a ticket is created or updated, and actions in one trigger can affect the actions in another.

To reorder the list of triggers
  1. Click the Admin icon () in the sidebar, then select Triggers.
    Zendesk Classic: Select the Manage menu, then select Triggers and mail notifications.
  2. Click Reorder at the end of the list of active triggers.
  3. Click and drag triggers to new locations as needed.
  4. Click Done.

Editing and cloning triggers

You can edit and clone triggers. Cloning a trigger creates a copy that you can modify and use for some other purpose.

To edit a trigger
  1. Click the Admin icon () in the sidebar, then select Triggers.
    Zendesk Classic: Select the Manage menu, then select Triggers and mail notifications.
  2. Locate the trigger you want to edit and click Edit.
  3. Modify the title, conditions, and actions as needed.
  4. Click Update Trigger.
To clone a trigger
  1. Click the Admin icon () in the sidebar, then select Triggers.
    Zendesk Classic: Select the Manage menu, then select Triggers and mail notifications.
  2. Hover your mouse over the the trigger you want to clone and click Clone .
  3. Enter a new name for your trigger and modify the conditions and actions as needed.
  4. Click Add Trigger.

Deleting and deactivating triggers

If you decide that you no longer need a trigger, you can either delete it or deactivate it. Deleting a trigger means that it's gone and can't be retrieved. You can instead deactivate triggers. Deactivated triggers are listed in a separate table under Admin > Manage > Triggers and email notifications and can be reactivated if needed.

To delete a trigger
  1. Click the Admin icon () in the sidebar, then select Triggers.
    Zendesk Classic: Select the Manage menu, then select Triggers and mail notifications.
  2. Locate the trigger you want to delete and click Edit.
  3. Click Delete.
To deactivate/activate a trigger
  1. Click the Admin icon () in the sidebar, then select Triggers.
    Zendesk Classic: Select the Manage menu, then select Triggers and mail notifications.
  2. Locate the trigger you want to deactivate and select Deactivate. This command appears when you move your mouse over the trigger in the list of triggers. The trigger is deactivated and displayed in the list of inactive triggers.
  3. To reactivate the trigger, select it from the list of inactive triggers and select Activate.
Note: If you accidentally delete your default triggers (Zendesk triggers to get you started), you can quickly rebuild them. For more information, see Resetting default triggers.
 

Comments

User photo
Diego Prado

I am trying to understand a little bit further the triggers and automation execution.

If an action consists of accesing a target:

  - Is there a way for the target to inform that it failed to perform its action?

  - If so, and one condition of the trigger was a change of status, Does it reverse the change that caused the trigger?

  - On the other hand, assuming that the target can inform that it failed, and there are two actions in the trigger (action 1 call the target, action 2 add a tag). Does the tag get added?

Basically I wanna know how does the trigger / automation behaves upon an error during its execution.

May 10, 2011 09:35
User photo
Anton de Young
Zendesk

@Diego

Even if the target action fails, the other actions (if any) in the trigger will succeed. A failure generates a log file and we (Zendesk support) can investigate individual tickets when you believe a trigger action has failed. At this time, there is no event failure notification that will directly inform you when something like this occurs. However, you will have an indication if the target fails repeatedly. Here's the information from the user's guide topic on targets:

"Zendesk attempts to send the notification 10 times. If all attempts fail, the target is deactivated. You’ll then need to edit and test and reactivate the target before you can try to use it again."

May 10, 2011 10:30
User photo
Sarah Manley
wikia

HI - I would like to set a trigger for one of my custom ticket fields that send a specific response if a user pics a specific option from a dropdown menu. Is this possible? I am not seeing it as an option and it is something i very much want to do.

The example is on my submit a request form I have added a custom ticket field that states "I would like to" the with a dropdown of different options. If the user chooses, "close my account" I would like to send an automatic macro so an agent doesn't have to look at it. Is this possible?

June 01, 2011 12:01
User photo
Anton de Young
Zendesk

Sarah, 

Yes, you can do this. Custom fields have tags. You set them when you're creating the custom drop down field options. Just use the tag in a Tags condition in a trigger and then set the actions you want based on the tag. 

June 01, 2011 15:45
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
jerlin

s there a way for the target to inform that it failed to perform its action?

 

http://www.labortimetracker.com/

June 17, 2011 05:23
User photo
Emilianowicz, Vincent

This is a great explanation of triggers, but I am struggling with setting up a trigger to do something that I don't feel is covered here. 

I would like that when one of the Agents marks a ticket solved that if the user comments on that ticket (by email or the website) that the ticket is marked to open again. 

So I set if Ticket is Updated and Status is Solved then Set Status to Open, but now if an agent updates a ticket with a reply and sets it to Solved then it immediately reopens the ticket.  Is there a way to get it to check what the status of the ticket was before the action?

June 20, 2011 08:34
User photo
Emilianowicz, Vincent

Disregard my question, I figured it out and now I feel dumb about it, haha.

June 20, 2011 08:36
User photo
Heidi Helm

Hiya. I would like to set up a trigger that emails the assignee when a ticket has not been updated for at least 48 hours. And also one that will email a specific admin of any new ticket that has not had a first response within at least 72 hours. I couldn't figure out if this is possible or not. Thanks! —Heidi

August 03, 2011 14:02
User photo
Jill Kaselitz
Zendesk

Hi Heidi,

You will be able to accomplish this through automations instead of a trigger. Since automations are time based, you will be able to set up your requested workflow as 2 different automations. You can read more about automations and how to configure them at https://support.zendesk.com/entries/20012032-streamlining-workflow-.... Please feel free to let us know if you have any questions within the comments section of this article.

Zendesk Support,

Jill

August 03, 2011 14:53
User photo
Heidi Helm

Thanks Jill, that sounds great, I knew it had to be doable! Hh

August 03, 2011 14:59
User photo
Bhavin Parikh
magoosh

Thanks for the help on triggers!  I've set up a trigger that emails a response to customers based on a ticket created with certain words in the text comment area, but I can't figure out how to update the ticket using the trigger.  Can someone help?

September 15, 2011 08:48
User photo
Anton de Young
Zendesk

Bhavin,

Do you mean that aside from sending an email you also want to update ticket properties using the same trigger? Did I get that right? If so, all you need to do is add more actions to the trigger to set ticket properties. 

September 15, 2011 09:04
User photo
Joy Carletti
Zendesk

@Bhavin, You cannot update the ticket using the trigger, if by 'update' you mean adding comments.  However, if you look at 'All events and notifications' on your ticket' (link on the right hand side, above the ticket comments), it will show what notifications are sent out, based on what triggers, in the course of the ticket.  So it will show that the notification was sent based on your trigger.  You can also use the trigger action to change the status or priority of the ticket in the 'Perform actions' section, and that will be shown there as well.

September 15, 2011 09:05
User photo
Bhavin Parikh
magoosh

Yes, you got that right.  Basically, I want the trigger to update the ticket so any other agent who looks at that ticket can see the response that was sent to the customer.   I couldn't find an action to "set ticket properties". Is that an Action statement?

September 15, 2011 09:09
User photo
Bhavin Parikh
magoosh

@Joy,  I did mean adding comments.  Thanks for the info.

September 15, 2011 09:18
User photo
Sean G
othelpme

Hello,

I'm trying to create an automation to alert an assignee when a good satisfaction rating has been given on a solved ticket.

I've created the automation, made it active - but it doesn't work, even though the preview match brings up results.

Screenshot is attached.

What am I doing wrong? 

October 06, 2011 12:13
User photo
Joy Carletti
Zendesk

@Sean, You may want to consider removing the timing element from this and making it into a trigger instead.  Automations run once hourly, whereas triggers run as soon as the conditions of the trigger are met.  It looks like this should be working; but the timing may not be right for the automation to run yet? 

October 06, 2011 13:43
User photo
sophie

Hi

(sorry for my ugly english)

I would like to know how inverse the order of the answer in the email sended to the requester, I try to explain:

In the email with the answer of the support, the requester read the text of the answer uppon his request!

On the support page, to follow his request, it's in the right order: request and bellow the answer ...

So is it possible to have the same order in the answered email?

Thanks for your the info

 

October 19, 2011 04:35
User photo
Max McCal
Product Manager

Hi, Sophie - The comments in an outgoing email are always listed in newest to oldest order. You might be able to make changes to this using Liquid templates (http://bit.ly/vgPvII), but we don't really have any documentation on doing this specifically.

October 24, 2011 15:58
User photo
Arlene Michael

Good Afternoon,

I have set up a trigger that will send an e-mail to an organization when a ticket is open that meets certain criteria.  I also need the e-mail to be cc'd to an end user....the same one every time.  She is a member of the organization, but will not be given agent privileges.  Can this be done with a trigger, or some other function?  When I tried, only agents were listed in the dropdown of e-mail recipients.  Any help would be most appreciated.

November 08, 2011 11:20
User photo
Max McCal
Product Manager

Hi, Arlene -

You can't use a trigger to send an email directly to an End-user like you're describing, but if you're using our Enterprise subscription you could make the user a Light Agent, allowing her to be selected without granting her full agent privileges (http://bit.ly/rYLw40) or if you're not, you can send ticket content out of the system using Email Targets (http://bit.ly/vFgaLi). Targets won't make her a CC or allow her to respond and update the ticket, but you can send out all ticket comments using the placeholder {{ticket.public_comments_formatted}}. Let me know if you have any trouble with either!

November 08, 2011 14:41
User photo
Arlene Michael

Hi Max,

Thank you for your quick response.  :)

Hmmm....not sure I understand Targets.  I looked at the page you linked to, and didn't see how I could send just a plain e-mail when the ticket is opened.  Can you direct me to something more detailed so I don't keep asking you silly questions?  :)

Thanx,

Arlene

November 08, 2011 14:54
User photo
Max McCal
Product Manager

Hey, Arlene -   I created a ticket for you, since I think this is going to get pretty specific pretty quick. Thanks!

November 08, 2011 16:48
User photo
Wendy
taskrabbit

I'd currently have a trigger to notify my target (hipchat message) when a ticket is assigned to a group. Unfortunately it notifies the target EVERY time the ticket is updated even though the group isn't changed. Is there a way for a trigger to fire once and then stop.. never to fire again?

November 16, 2011 15:40
User photo
Max McCal
Product Manager

Hey, Wendy - 

I recommend adding a condition to the trigger that gets nullified by actions of the trigger. For example, if your "meet all of the following conditions" section tests for a particular tag being absent, and that tag is added by the trigger, the next time the ticket is updated, the trigger won't fire because the tag is present now. 

For example: 

emailsent.png

Once this has been set up, the first time the conditions are met, the email will be sent and the tag will be added. The next time the ticket is updated the conditions won't be met, because now the tag is present. That's the best way to keep a trigger from getting sent out over and over.

Let me know how it works out!

November 16, 2011 16:39
User photo
Wendy
taskrabbit

Thanks! That fixed it :)

November 16, 2011 16:57
User photo
Molly
fersupport

Occasionally end users reply to closed (not solved) tickets, which creates a new ticket that is marked as follow-up to the original.  However, the "Notify all agents of received request trigger" does not fire when this new ticket is created.  Is there a way to create a trigger for these instances?  Thanks.

November 30, 2011 15:38
User photo
Jill Kaselitz
Zendesk

Hi Molly,

We'll want to look into this for you as the 'notify all agents of received request' trigger should fire when follow up tickets are created. Send us an email to support@zendesk.com with a ticket number where this trigger didn't fire and we'll gladly take a look.

December 01, 2011 08:37
User photo
Daniel
solver

We'd like to have a trigger condition that is satisfied when Zendesk creates a new user account for the requester.  There doesn't seem to be a way to do this now -- have I missed something?

I understand that trigger conditions are based around tickets, not users.  But we're trying to capture situations where a user submits a ticket for the first time, and this results in creation of a Zendesk user account for them.  We'd like to distinguish this from situations where the user submits a ticket, and already has a Zendesk user account.

So there should always be a ticket and a ticket.requester in this situation -- we're looking for a way to tell that the ticket.requester is 'new'.  Thanks.

February 08, 2012 12:46
User photo
Nathaly Ceballos

How can I deactivate the notification verifying your order? Can you help me?

Thank you 

February 22, 2012 12:53
User photo
John Berlet
evolvondemand

Hello,

         Is it possible to prevent the Notification of an agent (via email or other notification channel) when the comment/ticket update is performed by that agent? Example, if I as an agent updated a ticket that is assigned to me can the comment update trigger be designed in such a way that the alert is not sent to me as an agent, just the requester?

I don't see a Condition in the Automation or Triggers menu that would allow this and I am trying to reduce the amount of alerts sent to my agents. Every time they update their ticket, they are getting an alert and they should not if they are ones who made the comment.

Thanks!

John

April 25, 2012 13:20
User photo
Joy Carletti
Zendesk

Hi John,

Our default 'Notify assignee of comment update' trigger is actually designed so that it shouldn't be notifying the assigned agent when they update their own tickets - it's the condition "Assignee is not (current user)" that ensures this. You may want to compare the default conditions with your own conditions to see if changes have been made so that you aren't getting over-notified, and if you have specific questions, feel free to reach out to us at support@zendesk.com for some additional help with troubleshooting your triggers.  The default conditions are available at https://support.zendesk.com/entries/20251778-notify-assignee-of-com...

April 25, 2012 14:19
User photo
John Berlet
evolvondemand

Joy - thank you, I will test adding that condition. Does this condition also account for if agents reply/update a ticket they own via email e.g. how would Zendesk know that the email request/update for the ticket Assignee is NOT the current user?

Thanks!

John

April 25, 2012 14:38
User photo
Joy Carletti
Zendesk

@John - Should still work in that case! Updating the ticket, whether by email or web portal, makes the agent (assignee) the current user. 

April 25, 2012 15:59
User photo
Mathias Bucht
ismotec

We want a trigger to fire for certian end users. When I use the condition Requester is not, I would like to enter an e-mail address that belongs to an end user, not an agent.

the same limitation is a problem when we want to create a view based on one end user's tickets.

June 28, 2012 04:41
User photo
Mark Dawson
Thomascook

Is there no way to fire a trigger based on a word or phrase in the subject line?

July 02, 2012 07:44
User photo
Fathy Elsherif

I want to CC an external email address on all tickets created from a particular organization. I added the Organization as well as a User account. When I went to Triggers, I couldn't select this person from the users to "CC". Is what I'm trying to do possible, should I follow some other steps to do this?

July 10, 2012 09:58
User photo
Chyrelle Rayman-Bacchus
subhub

Is it possible to set a trigger so that when a ticket is received with a certain subject it is deleted or closed immediately?

If this is not possible with the subject could it be based on a certain string within the description?

July 12, 2012 08:07
User photo
Christopher Miller
zephyr

We test driving the Enterprise Edition and I have a question. A "Light Agent" doesn't always have the characteristics of an Agent. For example, you can't assign a ticket to a light agent. However you can assign a ticket to a group with a light agent in it. 

So I am familiar with a light agent not being entirely an agent. Thus, how does a light agent play out with "Current User is Agent" Is this light agent included  in this or excluded from this parameter?

Cheers,
Chris 

August 29, 2012 12:31
User photo
Adam Rhine
coupapartner

Per Mathias and Fathy's comments above, we'd love the ability to either change the Requester to and End-User in our system via trigger, or to add an external or end-user email address as a CC via trigger. Right now, the only option seems to be to CC agents.

 

Thanks!

Adam

September 11, 2012 16:14
User photo
Adam Zabarsky

Hello there, 

I'm trying to figure out how I can create a trigger when a ticket is shared with JIRA. Seems like it should be possible, but I'm just not able to work it out.

Many thanks!

September 11, 2012 16:42
User photo
Rob Woolley
solium

What are the chances of allowing the triggers to be created/updated and deleted through the API? We're at the point where our triggers are very complex and I'd like to manage them more robustly in a version control system (for audit, replication and safer deployments).

September 12, 2012 13:58
User photo
Marvin Sebastian

hi, how do i notify an external target? i click the link "notifying external targets" but the page says that:

 

Oops.
The page you were looking for doesn't exist.

September 24, 2012 04:08
User photo
Sunny Mody
cloudsquads

Hi I am trying to create a workflkow based on several custom dropdown field selections using triggers,

please help me out

 

 

 
September 27, 2012 01:34
User photo
Ian Klein

I just read this:

 

Using this condition you can check for the presence of single words and strings of words in either the subject or body of the comment. You can use any of the following operators:

  • Contains at least one of the following words
  • Contains none of the following words
  • Contains the following string
  • Contains not the following string
And I'm realizing something I need is not here - names, "contains at least one of the following strings".
Any chance that's on the roadmap?
Thanks!
-Ian
October 02, 2012 11:35
User photo
Albert Ramstedt

I am not sure how to get this right: I want to alter the "Notify requester of comment update" to not mail the original requester if I have forwarded to a third party (I do this by adding a cc and clearing the "to"). If they reply I do not want the original requester to see this reply. Or am I doing this wrong? Is there some other way to forward a ticket to a third party?

December 18, 2012 08:27
User photo
Justin Seymour
Zendesk

Ian: I'm not sure I follow! What do you want to isolate with those conditions? 

Albert: A third-party outside of Zendesk will always reply with a public comment. It sounds like you might have to disable that particular trigger if you're always looping in outside people. 

December 18, 2012 11:10
User photo
Ian Klein

Justin - I was thinking if there were three search strings, for example "PRN Media Monitoring" "Social Media Metrics" or "PRN MM"... where each string contained multiple words...

 

...I would like to put that in a single line rather than have to make a condition for EACH string.

 

Make sense?

 

Thanks!

 

-Ian

December 18, 2012 11:14
User photo
Justin Seymour
Zendesk

Indeed! You'll have to create individual conditions for now, though I see how this would be useful. 

December 18, 2012 11:16
User photo
Bob Johnson
accuvantlabs

We have system generated alerts for different events.  Some are employee onboarding, changes, terminations, system issues, etc.  Each alert sends with a different string in the subject or body.  I'm trying to find a way to route the ticket to a particular agent based on the sender address or email subject or email body.  Is this possible?

December 19, 2012 18:06
User photo
Justin Seymour
Zendesk

Hey Bob: 

You can use the Comment text condition to look for exact strings or specific words. This particular condition looks at both the subject and email body. If the end-user has a common domain and is mapped to an organization, you can simply use the Organization condition to route the ticket. 

https://support.zendesk.com/entries/20049342-creating-managing-and-...

December 20, 2012 04:58
User photo
Anusuya Nanjan

I am trying to create a trigger that sends a mail to all the agents with the priority in the subject line and the body.I used the placeholder {{ticket.priority}}.But I just see a blank space in the place where i want the priority.What could be the reason?

December 31, 2012 12:46
User photo
Justin Seymour
Zendesk

It looks like your trigger is configured correctly, and I've tested this on my account with success. The priority appears in the subject as it should. Could you give it another go and take a screenshot of what you're seeing? 

December 31, 2012 16:48
User photo
Anusuya Nanjan

I still see the same problem.I have attached the mail(Mail.jpg) we receive highlighting the problem and also the trigger we use(Trigger.jpg).

Further we customized the priority field to match our requirement.Could that be a reason?I am attaching that one too(CustomizedField.jpg).

January 02, 2013 10:51
User photo
Justin Seymour
Zendesk

Ah, I didn't know you were using a custom field. The priority placeholder draws from the system level priority field, which in your example ticket, has no value. You'll need to create a custom placeholder to use in conjunction with your severity field: https://support.zendesk.com/entries/20011631-using-placeholders#top...

January 02, 2013 11:24
User photo
Anusuya Nanjan

Thanks Justin.Sorry left out the "customized field" part :).

I have another question.Now the placeholder works fine but i do see some junk value following the severity,in the subject line.Am i missing something here?

January 02, 2013 11:57
User photo
Justin Seymour
Zendesk

The token you're referring to ensures that agent replies are associated with the right tickets. Only your agents can see the token, and it has no effect on end-user correspondance. This was part of a change we made in 2010 to improve mail delivery and email communication in general. It is not possible to remove the token or disable this feature! 

January 03, 2013 06:09
User photo
Claire
locisolutions

I'm trying to do the same as Mathias above, back in June 2012, but there doesn't seem to be a response. I want to reject tickets from specific end users but include a message as to why and what they have to do to resubmit the ticket. I figured a trigger was the way to do this, but can't select specific requesters.

February 12, 2013 19:14
User photo
Justin Seymour
Zendesk

Claire: You can blacklist or reject tickets from specific email addresses, but there's no way to send a custom message with it. Blacklisting is more of a security feature than ticket control, as it completely prevents tickets from reaching the help desk. Additionally, triggers do not include a list of end-users in the drop down menu, and there is no option to type in an address manually. I'm afraid we don't have a solution for what you're after! 

February 13, 2013 04:57
User photo
Jon Terry
Can I trigger workflows based on the geo-location info that appears automatically at the bottom of a submitted ticket? This seems quite accurate and much more convenient than asking a user to tell us where they are via a custom 'Location' field
February 26, 2013 21:09
User photo
Justin Seymour
Zendesk

The geo-location in the ticket is only for reference at the time being. There's no way to create triggers or automations around that data. Sorry! 

February 27, 2013 04:37
User photo
Brandon Pal
vfmleonardo

I would like to create a trigger that changes a field when a ticket is shared with JIRA.  In the trigger setup I'm not seeing any option for when a ticket is shared.  Is this possible? 

March 18, 2013 09:48
User photo
Brandon K.
Zendesk

Hey Brandon,

Our triggers don't have the ability to detect when a ticket is shared, unfortunately. If you are using a macro to send over a private comment with bug information, however, you could add a tag with that macro and then base a business rule off of it.

March 29, 2013 17:37
User photo
Adrian Dryglas
vsu

Hi,

How can I communicate with third party from within the ticket without having Requester notified? If I have a ticket on hold as I need additional information from third party - for example a vendor - how can I send e-mail and then receive response from supplier directly to ticket, so I can provide Requester with a solution? 

April 23, 2013 03:18
User photo
Brandon K.
Zendesk

Hey Adrian,

It looks like you posted this question in another forum and already got an answer so I'm going to post it here as well for anyone that sumbles upon this post instead of your other one. Credit goes to our forum user Annika Tol-Springest for this.

"I had the same problem and solved it by using the Linked Ticket App (it's in the Apps list in your ZD). You can create a child ticket that's linked to the parent ticket. That way you can communicate with a third party without having to change the original ticket. As soon as the third party gets back to you with the information you need, you can update the original ticket and notify the requester. 

Works really well :) good luck!"

April 23, 2013 16:24
User photo
James Palmer
omniis

Was wondering if I could use a trigger to bring up documentation (a note or document in word) and this is added into the ticket?

April 24, 2013 08:15
User photo
Brandon K.
Zendesk

Hey Jpalmer,

Although Zendesk doesn't have the ability to automatically pull information from a file on your local computer, we are planning on allowing triggers to activate macros in the near future. What you could do with this, is put all of the documentation you would want to pull from your computer and add it as a macro in your account. You could then have the trigger apply the macro which would place the information that you want in the ticket. I believe the apply a macro with a trigger functionality will be coming out in the coming months.

April 24, 2013 12:18
User photo
Jess P.
payperks

I'm trying to create a trigger that sweeps for tickets weekly and alerts the group (these are escalations and the agents they're assigned to aren't often signed into ZenDesk). I've built the main part, but I'd like to have dynamic content say which of the 4 agents in the group has tickets assigned and how many.

Is that possible?

 

 

June 17, 2013 09:17
User photo
Danielle Bradford
ilovebluesea

I created a trigger for "new tickets" coming from requesters to assignees. I am attempting to create a new trigger for when an assignee creates a ticket on the end user's behalf. 

I specified on the "new tickets" trigger a condition that "requester is not assignee", but when I create a ticket for an end user (myself as a test), I still set off the "new tickets" trigger. How do I get around this?

July 02, 2013 11:39
User photo
Bob Novak
Zendesk

@Danielle,

Your trigger should have Ticket is...:Created and Requester:Is not:Assignee as the conditions. It sounds like that was set up correctly. Can you try creating a ticket for a different end-user or test account other than yourself and see if the trigger still runs?

July 02, 2013 13:07
User photo
Jstewart
interactive360inc

Is there a possibility of adding an action to the triggers for Public Comment and Internal Comment? I can see using this for time when out of the office on holidays and/or vacation time to automatically make a comment on the ticket as well as any other actions that may be on the trigger.

July 10, 2013 10:03
User photo
Laura D.
Zendesk

Hi Jstewart, 

There isn't a way to do this, I'm sorry, it's only possible in macros. I also don't see anything like this on the roadmap currently either. 

July 11, 2013 11:57
User photo
Rstearns
digitalsmiths

Is there a way to leave a user in a Group but not have them get all the emails for that group? Our manager doesn't want to receive ticket emails unless he is assigned or CC'd. Without removing him from our groups I don't know how else to edit our triggers (the default ones, for the most part) to keep him from getting them.

July 15, 2013 06:47
User photo
Laura D.
Zendesk

Hi Rstearns, 

No, there is no way to stop a notification from going to one member of the group if there is a trigger or automation set up to notify the entire group. Would the option of creating a separate group for this supervisor and giving that group access to all tickets be a possible alternative? You could set up conditions to notify that group in only certain instances apart from when a ticket is assigned to a specific person. 

July 15, 2013 16:13
User photo
Rstearns
digitalsmiths

Laura - that would work for us but I didn't know you could do that. How would I set up something like that?

July 16, 2013 06:19
User photo
Brandon K.
Zendesk

Hello Rstearns,

The process that Laura outlined is fairly simple, you would just remove the manager from the group that is receiving notifications and set their user permission to be able to view tickets in groups that they do not belong to (this is the default setting).

Another process you might want to consider is to edit the message that is being sent out with that trigger and add a unique phrase that you can filter out on your email service. You can alter your trigger by going to Admin > Business rules > Triggers and editing the trigger in question, most likely Notify group of assignment. From there, add something to the action 'Email user' like Zendesk message #442. You could then go to your manager's email account and set up a filter to delete or send to spam any messages that contain the string 'Zendesk message #442'. This will allow you to keep your current workflow in Zendesk and still prevent your manager from seeing the message. Here's an article on how to set up a filter in gmail, if you aren't using gmail, you could probably search for instructions on how to set up a filter in whatever system your are currently using: https://support.google.com/mail/answer/6579?hl=en

 

July 26, 2013 09:41
User photo
Nathalie
conversocial

I've created a trigger so that I get emailed whenever a ticket that is not assigned to me gets updated. 

Commands: 
Ticket is - updated

Ticket status is - less than solved

Ticket assignee is not-  me

It's working pretty well but I seem to now be getting an email when tickets are solved too. Do I need to put the status as less than on hold for these to stop? Will I still get notifications of on hold tickets being updated?

I also seem to be getting emails whenever I solve something too... which I didn't used to get. Can't figure out why. 

Any advice would be much appreciated! 

August 02, 2013 04:00
User photo
Saad Siddiqui
groupon

I am new to ZD and was wondering if anyone can help with the following scenario

I am trying to figure out how we can use Assignee field to update the “Assignee Group” field to add the tag or just have the tag added when the “Assignee” field is updated

 

August 06, 2013 02:02
User photo
Dr. J
Zendesk

@Nathalie - Looks like you got some help in a ticket. Glad things worked out!

The solution was to add an argument that Current User Is Not Nathalie

August 13, 2013 13:24
User photo
Dr. J
Zendesk

@Saad - good question! - If you simply add tags to the user profile, or to the Organization, they will then be added to the ticket when the agent, or Organization member updates it.

This Article will walk you through adding tags to users and organizations in greater detail.

August 13, 2013 14:31
User photo
Danielle Bradford
ilovebluesea

@Bob I was using a different end user other than myself and the trigger still runs. I disabled both thinking it would simplify everything, but then after a week I realized that "new" tickets created by me for customers were not being received. Which is another issue. How can I see whether a ticket was actually sent?  

If there is no simple fix, can someone please create a private ticket with me to figure out what's going on? 

August 14, 2013 09:36
User photo
Dr. J
Zendesk

@Danielle - Can you please join me here so we can better discuss your issue? #Thanks!

August 14, 2013 09:53
User photo
David Greig
activ8it

Early in this document is the statement

"Each time a ticket is created or updated all of your triggers run; therefore, as you’re creating triggers you need to think about the order of triggers because an action in one trigger may change a ticket property that was changed by another trigger. If you're not careful, this can result in multiple email notifications being sent, which can create confusion for your customers."

Later under the heading "REORDERING TRIGGERS" the statement

"You can reorder your list of triggers, but keep in mind that all of your active triggers are run (first to last) each time a ticket is created or updated; therefore, the order of execution is important because actions in one trigger may affect the actions in another."

I assumed this meant that the triggers would be processed in sequence once and that the actions of one trigger could only affect the triggers later in the list. I recently discovered that this is not true (well, at least in the way I had interpreted it). I was surprised to find that a trigger two triggers run with the one later in the sequence running before the earlier one. Based on my subsequent investigation I believe that when a ticket is updated the actual process is more like:-

  1. A list of triggers is extracted and stored in order
  2. The triggers are evaluated in order until the first one whose conditions are met (i.e. it “fires”) at which time that trigger is flagged as having been fired and processing of the trigger list then starts again from the beginning of the trigger list but ignoring an triggers which have already fired
  3. Processing of the trigger list eventually finishes when the list has been completely processed without a trigger being fired.

This means that any time a trigger updates a ticket any of the earlier triggers which didn’t previously fire may now be in a position to fire (depending on what was updated in the ticket).

It’s pretty easy to demonstrate how this works. Just create four triggers in your Sandbox:-

  1. test for existence of "trigger_test" tag - action - add "tag_found" tag
  2. test for non-existence of "trigger_test" tag - action - add "trigger_test" tag
  3. test for the existence of "trigger_test" tag - action - remove "trigger_test"
  4. test for the existence of "tag_found" or "trigger_test" tag - action - remove "tag_found" and "trigger_test"

For extra control over which ticket(s) fall into the test I’d suggest adding an addition “ALL” test to each of the four trigger – Test for the existence of “trigger_test_master” and add that tag to the tigger(s) you use for the tests.

Then:-

  1. Update the ticket(s) by adding the "trigger_test" tag. Check events paying attention to the order in which the triggers have fired (it will be 1, 3, 2, 4).
  2. Update the ticket ensuring the "trigger_test" tag is not present (which it shouldn’t be already). Check events (the order will be 2, 1 ,3, 4)

If you want more try any or all of the following, re-order triggers to 3, 1, 2, 4; 1, 3, 2, 4; 2, 1, 3, 4 or 2, 3, 1, 4 and repeat both ticket updates.

My feeling is that the documentation needs to be updated to make people more aware of the way triggers are processed.

 

August 26, 2013 19:31
User photo
Laura D.
Zendesk

Hi David, 

The order of triggers is important, though you bring up a good point that we could use some additional documentation to clarify how they work :)

In regards to the actual process, where you list three steps about how triggers work, you're close but there are some differences. Here's an example:

  • First, a ticket exists - it's updated and then checked against a list of four triggers in order: #1, #2, #3, #4. 
  • In this first pass, the ticket doesn't meet conditions in trigger #1, so that's skipped, it does meet the conditions in #2 (the items needing to be changed on the ticket are stored as needing to happen, but aren't yet made), the ticket doesn't meet the conditions for trigger #3 or #4. The entire list of triggers has been checked and so the system applies the changes required from trigger #2.
  • Since there were some changes made to the ticket the system runs through the list again, #1 - #4 in order. This time the ticket meets the conditions of #1 and # 4, those changes are made after going through the whole list and. This process repeats until the list is completed without requiring additional changes to the ticket. 

So, if we look at your description, rather than exiting the list after one trigger is applied the system runs through the entire list , applies any changes, and then runs through it again, until no changes are made during the run through. This is what can give the appearance of triggers running out of order when you look at the events log of a ticket, you're only seeing the list of triggers applied in the order they were applied, you're not seeing the complete list of what triggers the ticket was checked against.

Also, with your list of triggers #2 is not dependent on #1, in one case the tag is there and in the other case the tag is not there. Since the actions on trigger #1 don't remove the tag, #2 doesn't apply until the second run through of the list after #4 has removed the tag. If you wanted to see these run 1-2-3-4, You could combine the first two triggers into one and then it would work in order, or you could have the second trigger look for the "tag_found" tag instead. The combined trigger would check for the "trigger_test" tag under the "any" section and then add it in the actions section (if it's already on the ticket it won't be duplicated so that's fine). 

I hope this helps clarify how triggers run in order, we'll get the article updated as soon as possible. Thanks for the feedback!

August 27, 2013 13:52
User photo
David Greig
activ8it

Laura,

Could I suggest that you hold off updating that documentation until you’ve reviewed my comments below.

If I understand your explanation you are saying that in any one pass through the triggers all conditions will be checked against the ticket’s properties as at the start of that pass regardless of any updates performed by previous triggers. I also understand that you are saying that each pass runs from the start of the trigger list to the end of the list (less any triggers which have already “fired”).

In order to test this I have added some more triggers to my test bed. For the purposes of proving or disproving your suggested processing method they are now four triggers which test for the presence or absence of a single tag (i.e. two triggers covering the two possibilities for one tag and two triggers covering another tag). As far as I can tell, for your suggested processing method to be true, I must get two emails on the very first pass after a ticket update and the sequence of the triggers can’t possibly reset in the first pass until, at least, after second email has been sent.

Please review ticket #181 in our Sandbox. According to my understanding of your explanation:-

  • In test 1 (trigger_test tag present) trigger 7 (send an email if trigger_test tag present) and trigger 8 (send an email if tag_found tag not present) must fire before pass 1 completes yet neither fires in pass 1 (as indicated by the sequence resetting from trigger 3 back to trigger 1).
  • In test 2 (trigger_test tag not present) trigger 6 (send an email if trigger_test tag not present) and trigger 8 (send an email if tag_found tag not present) must fire before pass 1 completes yet neither fires in pass 1 (as indicated by the sequence resetting from trigger 2 back to trigger 1).

Do you agree that the sequence that the triggers fire in these tests does prove that your suggested trigger processing doesn’t fit with what actually happened? If not, can you explain how the triggers processed in the sequence they did.

Regards,

David.

PS. Incidentally, the triggers in the two tests I performed against ticket #181, as did the ten tests I performed against ticket #176, all fired as I would have expected if as soon as a trigger fires processing of the trigger stops and control goes back to the top of the trigger list (with any triggers which have already fired being ignore in any subsequent processing).

August 29, 2013 00:29
User photo
David Greig
activ8it

Laura,

Would you be able to check ticket #185 in our sandbox environment please. This time I have set up:-

1)      26 triggers (one for each letter of the alphabet) which:-

a)      test for the existence of that particular letter’ tag

b)      add the tag for that letter’s mirror image letter (i.e. the ‘A’ Trigger adds the ‘Z’ trigger)

c)       removes that letter’s tag

2)      26 triggers (in reverse alphabetic order) which:-

a)      test for the non-existence of that letter’s tag

b)      add that letter’s tag

3)      1 trigger which removes any remaining tags

Running a test with no existing letter tags I believe you would be expecting:-

1)      Pass 1 – no letter tags exist

a)      Bypass the first 26 triggers (as all would fail the test for existence of their letter tag)

b)      Run each 26 triggers to create all the letter tags

c)       Run the finalisation trigger which would remove the 26 letter tags.

2)      Pass 2 – no letter tags exist

a)      Bypass the first 26 triggers (as all would fail the test for existence of their letter tag)

b)      Bypass the 26 create letter tag triggers as they had already run in Pass 1

c)       Bypass the finalisation trigger as it had already run in Pass 1

3)      Pass 3 – not required as Pass 2 had completed without any triggers firing

Instead what actually happens is:-

1)      Pass 1 – no letter tags exist

a)      Bypass the first 26 triggers (as all would fail the test for existence of their letter tag)

b)      Execute the set triggers for the letter ‘Z’

2)      Pass 2 – tag ‘Z’

a)      Bypass the first 25 execute triggers (‘A’-‘Y’)

b)      Execute the ‘Z’ trigger (remove the ‘Z’ tag – add the ‘A’ tag)

3)      Pass 3 – tag ‘A’

a)      Execute the ‘A’ trigger (remove the ‘A’ tag – add the ‘Z’ tag)

4)      Pass 4 – tag ‘Z’

a)      Bypass the first 27 triggers as they either fail or they’ve already executed

b)      Execute the set triggers for the letter ‘Y’

5)      Pass 5 – tags ‘Y’ and ‘Z’

a)      Bypass the first 24 execute triggers (‘A’-‘X’)

b)      Execute the ‘Y’ trigger (remove the ‘Y’ tag – add the ‘B’ tag)

6)      Pass 6 – tags ‘B’ and ‘Z’

a)      Bypass the first trigger

b)      Execute the ‘B’ trigger (remove the ‘B’ tag – add the ‘Y’ tag)

7)      Pass 7 – tags ‘Y’ and ‘Z’

a)      Bypass the first 28 triggers as they either fail or they’ve already executed

b)      Execute the set triggers for the letter ‘X’

8)      Passes 8 – 36 - the pattern continues

9)      Pass 37 – tags ‘O’ – ‘Z’

a)      Bypass the first 36 triggers as they either fail or they’ve already executed

b)      Execute the set triggers for the letter ‘N’

10)   Pass 38 – tags ‘N’ - ‘Z’

a)      Bypass the first 13 execute triggers (‘A’-‘M’)

b)      Execute the ‘N’ trigger (remove the ‘N’ tag – add the ‘M’ tag)

11)   Pass 39 – tags ‘M’ and ‘O’ - ‘Z’

a)      Bypass the first 12 triggers

b)      Execute the ‘M’ trigger (remove the ‘M’ tag – add the ‘N’ tag)

12)   Pass 40 – tags ‘N’ - ‘Z’

a)      Bypass the first 26 execute triggers (‘A’-‘Z’) – these have already executed

b)      Bypass the next 13 triggers (‘Z’ – ‘N’) – they have already processed and their tags already exist

c)       Execute the ‘M’ tag create triggers

13)   Passes 41 – 52 – the remaining triggers (‘L’ through ‘A’) are executed

14)   Pass 53 – tags ‘A’ – ‘Z’

a)      All tags are removed

15)   Pass 54 – no triggers process – no further action required.

Is that the way you see it?

Regards,

David

September 01, 2013 22:08
User photo
Laura D.
Zendesk

Hi David,

I'm sorry I misunderstood some of the information I was given last week.

I confirmed the following with one of our senior Product Managers: triggers go in order from first to last. If a ticket meets the conditions of a trigger, that trigger will fire, the current pass will skip any remaining triggers and start over from the beginning of the list of triggers, run through the triggers again, skipping any triggers that have already updated the ticket. That process will repeat until one pass is completed without any of the triggers firing - you're right.

I'm a little too late to assess exactly what happened with ticket #181 because the "last updated" timestamps on several of the triggers are from after the ticket was made and I'm not sure if the conditions and actions are exactly the same as they were before the ticket was updated.

Ticket #185 and the associated triggers are simply too much to check - I've also done more testing and from what I can see the triggers are running as you described.

What could be throwing off your tests is that if a trigger does something that doesn't actually result in a change in the ticket (it adds a tag that's already on the ticket) then that trigger doesn't show as firing even though the ticket met the conditions in that trigger. This could be confusing the issue if in a future pass the ticket meets the conditions and the trigger fires and updates the ticket We're going to have to look into that and get back to you; we'll do that through a ticket, separately from the automation ticket, I'll create a new one for you.

At this point, I'd say we're best off exploring this further in a ticket - we could use some clarification in the documentation and I'll pass notes along to the documentation team once we get the exact process figured out.

Thanks again for all the testing and your patience! 

September 04, 2013 15:49
User photo
Kathy Cooper

Our organization could really benefit from the capability to email an end user through a trigger without them having to be an agent.  Any hope of this for the future?

November 04, 2013 08:54
User photo
Brandon K.
Zendesk

Hey Kathy,

You could do this with Targets in Zendesk. If you go to Admin > Settings > Extensions and then add a target you can choose to set it as an email target. This will allow you to specify any email address and a subject line as well as the name of the target for organizational purposes. Once you've created the target, you will see a new action appear in your triggers called 'Notify target' that works similarly to the email user action. The only difference is that you cannot set the subject line through the trigger, only the body of the email. The subject line can be updated directly through the target, however.

November 04, 2013 09:27
User photo
Kathy Cooper

Thank you.  That worked.

November 04, 2013 09:51
User photo
Nathan Evans
arbitersports

Is there a way to automatically increase a numeric custom field?  I want to set a trigger that when we receive the satisfaction rating for a customer, we automatically increase or decrease the satisfaction level for the organization and user. 

The goal is to use other triggers to ensure unhappy clients get top service.

November 25, 2013 16:54
User photo
Avi Warner
Zendesk

@Nathan, there isn't but that's an interesting use case. You can set a custom user or organization value, but you can't iterate it (+1 or -1 for example). Definitely do share that use case in our Product Feedback forum though!

November 27, 2013 12:59
User photo
Chris Cogdon
instartlogicinc

By "Each time a ticket is created or updated all of your triggers run; therefore, as you’re creating triggers you need to think about the order of triggers because an action in one trigger may change a ticket property that was changed by another trigger." I assume what is really meant is "one trigger may _test_ for a property that was changed by another trigger"

December 02, 2013 17:08
User photo
Chris Cogdon
instartlogicinc

Questions about "Ticket: Comment is"... what is the difference between "Ticket is public" and "Ticket is present, and requester can see".  I.e, what classes of comments might the requester be able to see, but would not be considered "public"?

Also, I assume that if any update did _not_ contain a new comment, then all 4 conditions will be false. Is this correct?

December 02, 2013 17:12
User photo
Laura D.
Zendesk

Hi Chris, 

I think we mean the same thing, just to make sure here's a very basic example:

If I have a trigger that looks for a condition, let's say status is "open" that also adds a tag "hello" and another trigger further down in the list of triggers that looks for tickets that are open and have the "hello" tag that removes the "hello" tag this is how the triggers will interact with the ticket:

  • ticket gets updated
  • trigger #1 is compared to the ticket, the ticket meets the conditions so the tag "hello" is added
  • instead of continuing to be compared to other triggers further down the list, the ticket goes back up to the top of the trigger list. Now it has an updated definition (since it now has the tag).
  • the ticket starts going down the list of triggers again. This time trigger #1 is ignored because it already updated the ticket. Now the ticket meets the conditions of the second trigger - the one that removes the "hello" tag
  • the tag is removed
  • the ticket is checked against the list of triggers one more time, since it no longer meets any of the conditions of the triggers or they've already updated the ticket, the loop is done and nothing more will happen until the ticket is updated again. 

 

As for the "Ticket: Comment is:" condition:

  • "Ticket: Comment is: public" - comment is public: end-users, agents, and light agents can see it. 
  • "Ticket: Comment is: is present, and the requester can see the comment" - this would be relevant if you have agents sometimes submit tickets because agents can see private comments as well as public comments. Basically it works with the privileges of the requester if it's an agent. 
  • "Ticket: Comment is: is present, (public or private)" - this would send a notification either way - it just makes sure a comment was added.

I hope this helps, please let us know if you have more questions!

 

December 04, 2013 11:34
User photo
Chris Cogdon
instartlogicinc

Thanks for the response Laura.

What you said implies that as soon as a trigger matches its conditions, it will apply the action, and then "go back to the start" and re-check all the triggers _except_ the one that just fired. Confirm? If that's true, then I think the documentation should make that clear, since there's no mention of that logic.

Also, using your example, if once trigger added the tag, and another removes it, this implies that the first trigger will re-fire UNLESS Zendesk keeps track of which triggers have fired and will never re-fire them for that event. Confirm?

(PS: seems awfully complex compared to, say, just going through each trigger in turn and checking conditions against its current state, which previous triggers may have modified. Are you _sure_ the "stop, and go back to the top" logic is actually what is happening?)

Regarding "Ticket: comment is:"... I understand now. Thanks. (Bit of a hard one to wrap one's head around ;) )

You didn't answer the last question: If any "ticket comment is..." condition is set, and the update did _not_ include any kind of comment (e.g.: just a status change), then that particular condition is always false. Correct?

December 04, 2013 11:57
User photo
Laura D.
Zendesk

Of course, there's a lot to triggers ;)

Yes - if a trigger updates a ticket, after being updated the ticket goes back to the start of the trigger list. It'll then start down the list again, skipping any triggers that have already updated the ticket. This means a ticket could loop through the trigger list several times before all of the triggers have either updated it or been skipped because the ticket never matched their conditions.

Triggers don't re-fire within the same cycle because Zendesk tracks which triggers have fired on a ticket during each loop. A cycle is the entire process of a ticket being checked against triggers - there's no precise number of loops that will happen within a cycle because it depends on the number of triggers you have and how many of them apply to a given ticket. In other words, a trigger will never update a ticket twice within the same cycle. 

I am sure of the path a ticket follows (we call it a "cascade") - and I agree it's complex. My guess is that there are probably some engineering decisions that necessitated this but I haven't dived in deep enough to be able to say for sure (I'd certainly like to at some point!). 

Interestingly, automations actually work a bit like you describe: a ticket exists in "state A" and you have 5 automations. It's time for automations to run (they only run once an hour). When automations run for that hour they only see the ticket in state A - the actions of the automations that apply are noted, all of the actions are taken at once, and that's it until the next hour. Effectively, tickets don't change as automations run - the actions of one automation won't impact another automation's likelihood of updating a ticket until the next hour. 

Sorry about the question, didn't mean to skip it: you're right. If a ticket update doesn't include a comment then none of those four options apply and the condition won't be met (and the trigger therefore won't do anything to the ticket). 

 

I agree that the documentation needs extra clarification - in fact we're working on an update to this and a few related articles to better convey how triggers work, we'll make a note of when the updated versions are out. 

Let me know if I can help with anything else!

December 04, 2013 14:23
User photo
Alison Vogel

Hello,

I would very much like to be able to set one or more trigger conditions on the ticket subject field and/or requester field. Because of the way we've set up our e-mail channel, we're getting a few tickets that result from a cc to noreply@ourcompany.com, which sets the requester field  to noreply. I'd like to set up a trigger to filter them out. Another way to filter them would be to look for a string that is commonly used as the ticket subject in such cases. I cannot figure out a way to do either of those things. Any suggestions?

Thank you!

December 19, 2013 15:04
User photo
Anthony Roman
Zendesk

@Alison - What you can do is to add a specific tag into the user profile of noreply@ourcompany.com in your account so that all tickets that this user will create will contain that tag. Now that we have a tag to identify tickets, you can use this tag in your trigger condition "Tags contains some_tag" to get all tickets from this user.

Hope this helps. Thanks!

December 22, 2013 18:51