Triggers are powerful, event-driven automations that run in real time when specific conditions are met. They act as a central element of a Zendesk set-up and form the foundation for efficient ticket handling, intelligent routing and a streamlined customer experience. By using triggers, repetitive tasks can be automated, consistent handling of enquiries can be ensured, and time can be freed up so that the support team can focus on complex issues and customer interaction.
What are Triggers?
A trigger is an "if-then" rule that monitors tickets in real time. When a particular event occurs and the defined conditions are met, the trigger automatically carries out a series of predefined actions. Triggers are designed to respond instantly to changes and ensure that the right action happens at the right time.
Triggers can respond to a wide range of events, including:
- Ticket creation: A new ticket is received via email, web form, API, etc.
- Status changes: A ticket's status changes (e.g. from "Open" to "Solved").
- Field updates: A field in the ticket is updated, e.g. priority, group or a custom field.
- Tag additions or removals: A tag is added to or removed from a ticket.
- Requester changes: The person who created the ticket changes.
- Comments or updates: An internal note or a public comment is added.
Triggers vs. Automations: The crucial difference
In Zendesk there are two primary automation tools: Triggers and Automations. Understanding the difference is crucial for building an efficient workflow. The primary difference is when they run.
| Property | Triggers | Automations |
|---|---|---|
| Trigger | Events | Time |
| Execution | Real time (instantly) | Scheduled (e.g. every hour) |
| Purpose | Immediate reaction to changes | Follow-up actions based on elapsed time |
In short:
- Triggers respond to what is happening now. They act as first-line automation.
- Automations respond to what has not happened within a time frame. They act as a follow-up mechanism.
The anatomy of a Trigger: Conditions, actions and order
A trigger consists of three central components that together define its logic and function.
1. Conditions: "When should action be taken?"
The conditions are the criteria that must be met for the trigger to be activated. "AND" and "OR" logic can be used to build anything from simple to very complex rules.
Examples of conditions:
Ticket is CreatedStatus is Changed to "Solved"Custom Field "Priority" is "High"Tag "escalation" is PresentGroup is "Billing Team"
The more specific the conditions are, the more precise and predictable the trigger's behaviour becomes.
2. Actions: "What should happen?"
When all the conditions are met, the trigger carries out one or more actions. The actions are the desired results – e.g. assigning a ticket, sending a notification or updating a field.
Examples of actions:
Set Group to "Enterprise Support"Set Priority to "Urgent"Add Tag "escalation"Notify user "Support Manager"Set Custom Field "Escalated" to "Yes"
A single trigger can carry out several actions at once.
3. Order: "Who wins?"
Zendesk evaluates triggers in a fixed order from top to bottom in the list of active triggers. This is a central concept. When a ticket's conditions match a trigger, its actions are carried out, and the evaluation stops. This means that "the first match wins". If a ticket can match several triggers, it is the one highest in the list that runs.
Proven trigger patterns for workflows
Below are some common and effective patterns for structuring support processes.
1. Initial routing
Ensures that new tickets are sent immediately to the right team based on the information in the enquiry.
Condition:
Ticket is Created
AND
Form is "Enterprise Support"
Action:
Set Group to "Enterprise Support"
Set Priority to "High"
Add Tag "enterprise"
2. Escalation
Handles tickets that require special attention, e.g. when they have not been answered within a given time frame.
Condition:
Status is "Open"
AND
Ticket is Updated
AND
First reply time is More than 4 hours
Action:
Set Priority to "Urgent"
Add Tag "escalation"
Notify user "Support Manager"
3. Status handling
Automates status changes to keep the workflow moving and ensure that all steps are followed.
Condition:
Status is Changed to "Solved"
AND
Requester is Present
Action:
Add Tag "awaiting-feedback"
Set Custom Field "Solved Date" to Current time
4. Tag-based routing
Uses tags that are added manually or by other systems to control routing and prioritisation.
Condition:
Tag "billing" is Added
AND
Status is "New"
Action:
Set Group to "Billing Team"
Set Priority to "Medium"
5. Logic based on custom fields
Carries out actions based on data collected via web forms or other integration points.
Condition:
Custom Field "Order Type" is "Return"
AND
Ticket is Created
Action:
Set Group to "Returns Team"
Set Custom Field "Return Deadline" to "7 days from now"
6. Automatic confirmation and reply
Sends an instant confirmation to the customer, so that it is clear that the enquiry has been received.
Condition:
Ticket is Created
AND
Channel is "Email"
AND
Comment is Public
Action:
Email user "Requester" with template "Initial Confirmation"
Best practices: Robust and effective triggers
To avoid errors and ensure a stable system, the following best practices can be applied when building and maintaining triggers.
1. Be specific in your conditions
The more specific the conditions are, the lower the risk of the trigger being activated unintentionally.
✅ Good practice:
Ticket is Created
AND
Form is "Support"
AND
Custom Field "Product" is "Enterprise"
❌ Bad practice:
Ticket is Created
2. Understand the order
Since "the first match wins", the trigger order is crucial. The most specific and critical triggers (e.g. VIP routing) are placed at the top of the list before more general triggers.
3. Test thoroughly and systematically
A trigger that has not been tested sufficiently can create unforeseen consequences. Testing can include:
- New tickets: Simulating a customer's first enquiry.
- Updated tickets: Testing the response to changes.
- Different field combinations: Verifying the logic across scenarios.
- Edge cases: Handling empty fields or missing user data.
4. Use tags strategically
Tags are a flexible tool and can be used for:
- Tracking: Marking tickets as "escalated", "vip" or "needs-follow-up".
- Routing: Using tags such as "billing", "technical" or "sales" to control the flow.
- Reporting: Grouping tickets in dashboards for trend analysis (e.g. "first-contact-resolution").
5. Avoid conflicts
It is important to ensure that triggers do not work against each other. This can involve:
- A thorough review of the trigger order.
- Avoiding conflicting actions across triggers.
- Documenting the logic behind complex triggers, so that it is understandable for the whole team.
6. Document the logic
The purpose and background of a trigger should be clearly stated. Internal notes or separate documentation can ensure that knowledge is preserved and that future adjustments are made on an informed basis.
Trigger order: Prioritisation in practice
The importance of order can be illustrated with the following example, where there are two triggers:
Trigger A (placed at the top):
Condition: Ticket is Created AND Tag "vip" is present
Action: Set Priority to "High"
Trigger B (placed below Trigger A):
Condition: Ticket is Created
Action: Set Priority to "Normal"
If a VIP customer creates a ticket, Trigger A matches first and sets the priority to "High". The evaluation then stops, and Trigger B does not run. If the order is swapped, all tickets will get the priority "Normal" (including VIP tickets), because Trigger B matches first. This shows how critical the placement is.
Advanced condition logic: AND vs. OR
Logic can be combined to build precise rules.
AND: All conditions in the group must be met.
Status is "Open"
AND
Priority is "High"
AND
Group is "Support"
Result: The trigger only runs for open, high-priority tickets in the Support group.
OR: At least one of the conditions in the group must be met.
Tag "vip" is Present
OR
Custom Field "Customer Tier" is "Premium"
Result: The trigger runs for tickets that either have the "vip" tag OR where the customer is "Premium".
Logic can also be combined: (Ticket is Created AND Form is "Technical") OR Tag "urgent" is Present.
Overview of common actions
Actions are tools for shaping the ticket's life cycle.
Routing and assignment
-
Set Group: Sends the ticket to a specific department. -
Assign to User: Assigns the ticket to a specific agent. -
Assign to Group: Assigns the ticket to any agent in a group.
Status and priority
-
Set Status: Changes the status (e.g. to "Pending", "Solved", "Closed"). -
Set Priority: Sets the priority (e.g. "Low", "Normal", "High", "Urgent"). -
Set Type: Categorises the ticket (e.g. "Question", "Incident", "Problem").
Data and tags
-
Set Custom Field: Updates a custom field with a specific value. -
Add Tag: Adds one or more tags to the ticket. -
Remove Tag: Removes a specific tag.
Notifications and communication
-
Notify User: Sends a notification in Zendesk to a specific user or group. -
Email User: Sends an email to any email address, often used for notifications outside Zendesk. -
CC's and Followers: Manages who follows the ticket.
Forms and SLAs
-
Set Form: Switches the form attached to the ticket. -
Set SLA Policy: Applies a specific Service Level Agreement policy to the ticket.
Troubleshooting: When triggers do not behave as expected
Even well-designed triggers can produce unexpected results. Below is a troubleshooting guide.
Problem: The trigger does not run at all.
-
Solution:
- Check the conditions: Are all the conditions met? A single deviation can prevent it from running.
- Check the trigger order: Is the trigger being overridden by a trigger higher in the list? Use the "Why was this ticket updated?" link on the ticket to see which trigger ran most recently.
- Check whether it is active: Is the trigger switched on?
Problem: Tickets are being routed to the wrong team.
-
Solution:
- Verify the order: Is there a more general trigger above that "takes over" the ticket?
- Test the conditions: Create a test ticket that matches the expected conditions and observe the result.
- Check for conflicting actions: Does another trigger run afterwards and change the group again?
Problem: A trigger runs too often or on the wrong tickets.
-
Solution:
- Make the conditions more specific: Add more "AND" conditions to narrow the scope.
-
Consider the event: Should the trigger run on
Ticket is CreatedorTicket is Updated?Updatedcan in some cases be too broad.
Systematic testing: Ensuring quality in automations
A fixed testing process can be applied to ensure that new triggers do not introduce errors into existing workflows.
- Create dedicated test tickets: Use a test account or create tickets with specific data to activate the trigger.
- Verify all actions: Review the ticket after the trigger has run. Is the group correct? Have tags been added? Have notifications been sent?
- Test edge cases: What happens if a required field is empty? What if an agent manually changes something shortly after creation?
- Carry out regression testing: Ensure that the new trigger does not affect existing triggers. Test common scenarios to confirm that they still function as expected.
- Monitor it live: After launch, the trigger can be monitored via the audit log to identify unforeseen problems in a real environment.
Conclusion: From reactive to proactive support
Triggers are more than simple rules; they are building blocks of an intelligent, efficient and scalable support organisation. By designing, testing and optimising triggers, support can move from reactive to proactive. This supports consistency, reduces manual errors and gives agents a better basis for delivering high-quality customer service. Ongoing improvement of trigger logic is a central part of the work of delivering faster and more relevant help to customers.