Triggersare business rules that run immediately after a ticket is created or updated and automatically perform actions if specified conditions are met. For example, a trigger can be used to notify the customer when a ticket has been opened.
Triggers are composed ofconditions, which are the qualifications needed for the trigger to fire, andactions, which are performed when those qualifications are met (seeUnderstanding trigger conditions and actions). In other words, if the conditions are true, then the trigger will perform the actions.
There is a set ofstandard triggersthat you can use and you can also create your own triggers. Admins and agents in custom roles with permission to manage business rules can create triggers.
Creating triggers
Triggers are business rules that run immediately after a ticket is created or updated and automatically perform actions if specified conditions are met. There arestandard triggersand you can create additional triggers.
You must be an admin or an agent in a custom role with permission to create triggers.
The following video gives you an overview of how to add triggers:
Automating notifications with triggers [2:02]
- InAdmin Center, click
Objects and rulesin the sidebar, then selectBusiness rules > Triggers. - ClickAdd trigger.
Alternatively, you cancopy an existing triggerand modify it.
- Enter aNamefor your trigger.
Use a consistent naming convention to help you recognize similar types of triggers.
- (Optional) Enter aDescriptionfor your trigger.
You can provide details about what the trigger does. You'll be able to search for triggers based on description.
- Select an existingCategoryfor your trigger orcreatea new one.
- ClickAdd conditionto set up the trigger to meetAllorAnyconditions.
t条件所需的资格rigger to fire.
- Select aCondition,Field operator, andValuefor each condition you add.
The field operator determines the relationship between the condition and the value. For example, if you select the field operator "Is", your condition will need to be equal to the value. Different conditions will contain different field operators.
SeeBuilding trigger condition statements.
Note:It is recommended to keep your trigger statements simple. The more complicated a trigger is, the harder it will be to troubleshoot and maintain. - Click theAdd actionto set the actions that occur when trigger conditions are met.
- SelectActionand aValuefor each action you add.
- Enter the action information.
Depending on the action you select, you will enter different information. For example, if you select the "Type" action, you will need to select a ticket type.
- ClickCreate.
Your new trigger is added to the end of the list of triggers.
Note:Each business rule must be less than 65kb.
You can reorder the list of triggers (seeReordering triggers) or edit any trigger (seeManaging triggers).
37 Comments
Ezgi FilazoğluI think the part that's causing problems is that Ticket is Created, and Ticket is Updated cannot both be requirements, that's why it's not firing. If you remove "Ticket is Updated", it should be able to fire.The current user piece will make it so this only fires if a ticket is created by someone for themself, which is fine and should be okay.
After a ticket is created, all future updates are "Ticket Updates", but the very first one, is not considered a ticket update, so it's a conflict with "Ticket is Created".
Thank you for this answer @CJ:Ezgi FilazoğluI think the part that's causing problems is that Ticket is Created, and Ticket is Updated cannot both be requirements, that's why it's not firing. If you remove "Ticket is Updated", it should be able to fire.The current user piece will make it so this only fires if a ticket is created by someone for themself, which is fine and should be okay. After a ticket is created, all future updates are "Ticket Updates", but the very first one, is not considered a ticket update, so it's a conflict with "Ticket is Created".I have one moe question.So what kind of trigger should I create to receive a notification if an end-user makes a comment for ticket. İsn't it "Ticket is Updated"?
Hi Ezgi,
For my organization, I would make a separate trigger, set up like below to get emails flowing for ticket updates. If we assume your agents set to tickets to pending, and tickets only switch to open when the user replies (which is what happens automatically by default), this would work. It says that if a ticket is updated, and that update changes the status to open, and the update has a comment being added as part of it, email the assignee this template that includes a ticket link and the latest comment formatted in HTML.
I want to have a trigger that sends a notification to a webhook on certain conditions, but only when the ticket is created, not updated. But there's another trigger that has to run first that updates some fields on the ticket, and that field is part of the first trigger's conditions. I want to make sure the notification trigger runs only when the ticket is first created.
For more context, we have different tiers of customers, and we want to call PagerDuty when a sev1 ticket is opened by one of those tiers but not others. But the customer tiers are updated by a different trigger, which calls a webhook to a cloud service to get their tier information and updates a custom field with that. The trigger that updates the plan tier information runs before any others, but then the ticket shows as Open, not New. Will any tickets that depend on the ticket being Created, not Updated, still run in this case?
Hi Cory,
This should work as long as the trigger updates the custom field directly, meaning it contains the said action in the trigger itself.Multiple triggers can run on a single event/cycle. If the trigger that updates the custom field value is above in the trigger order than the one that notifies the webhook, then they should be able to run in the same event (creation event).
The only reason why this will not work is if the trigger that changes the field value is not the one directly changing the custom field value but is using a Webhook to update the ticket via API. The changes in the custom field value using this method will not occur in the same event where the trigger fired but will create another event that will fall under the "Ticket is Updated" condition.
This is also not a workflow that we recommend/support since it usually causes race conditions.
We're going crazy trying to figure this one out.
Aiming to run a trigger when a macro is applied. The macro adds an Internal Comment, two tags and assigns the ticket to a group. This should then send a templated email to the customer (currently cut off, but it's just an 'email user' action).
For some reason, this just doesn't work. All of the criteria are matched and Zendesk 'counts' the trigger as having run, but the email just doesn't send.
What are we doing wrong?
HiD.Fitz,
This would require deeper investigation. I've created a ticket on your behalf so we investigate this issue together. Kindly check your email for more information. Thanks!
Pleasesign into leave a comment.