Business Rules - Trigger order & conditions – Available ApS

Working effectively with Zendesk Support is not just about answering enquiries, but also about building an intelligent and self-running system. At the heart of this system are business rules - the rules that govern what happens to a ticket from creation to closure. Understanding these rules, including the order and conditions of triggers, is crucial to avoiding conflicts and unexpected behaviour and to ensuring a stable workflow.

The heart of Zendesk Support: What are business rules?

Business rules are the logical foundation on which a Zendesk setup rests. The rules define how Zendesk evaluates and carries out automated actions and support consistency, efficiency and correct routing.

The primary types of business rules in Zendesk are:

Triggers: React to immediate events, such as the creation of a ticket or an update. These are the most active and fundamental rules.
Automations: Run on a schedule (typically every hour) and check for tickets that meet certain criteria over a longer period (e.g. "if a ticket has been open for 24 hours").
Macros: Predefined sets of actions that agents can manually apply to a ticket with a single click to save time and ensure consistency.

This article focuses on triggers, since their immediate nature and order of evaluation are often the cause of the most complex challenges.

The crucial order: How Zendesk evaluates triggers

A central part of trigger logic is the order. Zendesk does not evaluate all triggers; evaluation stops as soon as a match is found. This principle is crucial for designing predictable workflows.

Zendesk evaluates triggers in the order they are listed under Admin > Business Rules > Triggers (from top to bottom). Three basic principles:

The first match wins: When a ticket meets the conditions in a trigger, the actions are carried out, and evaluation stops. Triggers further down the list are not evaluated for that ticket.
The order is crucial: The placement of a trigger is therefore just as important as the content. Important and specific triggers should be placed at the top.
No duplicate execution: A trigger runs at most once per event for a given ticket. A trigger that reacts to "Ticket is Created", for example, can only run once at creation.

A practical example:
Imagine the following two triggers:

Trigger A (placed at the top):
- Condition: Ticket | Subject | Contains | "Urgent"
- Action: Ticket | Priority | High
Trigger B (placed below Trigger A):
- Condition: Ticket | Group | Is | "Support"
- Action: Ticket | Priority | Normal

When a customer with the subject "Urgent: My system is down" creates a ticket in the "Support" group, only Trigger A will run. The ticket gets high priority, and evaluation stops. Trigger B is ignored, even though its condition is also met. If the order were reversed, Trigger B would run first, set the priority to "Normal", and Trigger A would not be evaluated.

The building blocks of logic: Condition evaluation

The conditions in a trigger are the logical tests that determine whether a trigger should run. Conditions can be combined to achieve the desired logic.

AND logic (all conditions must be met)

The default logic is that all conditions in a trigger must be true before the trigger matches.

Status | Is | Open
AND
Priority | Is | High
AND
Group | Is | Second Line Support

In the example, the ticket must be open, have high priority and be assigned to the group "Second Line Support". If a single condition is false, the trigger does not match.

OR logic (at least one condition must be met)

By using "Add another condition" and choosing "Meet ANY of the following", OR logic can be set up. Here only one condition needs to be true.

Tag | Is Present | "vip"
OR
Custom field: Customer Tier | Is | "Premium"
OR
Organization | Is | "Strategic Partner"

If a ticket either has the "vip" tag, is from a "Premium" customer or belongs to a "Strategic Partner" organisation, the trigger matches.

Combined logic (AND and OR together)

Combining AND and OR logic makes it possible to control things more precisely, where groups of OR conditions must collectively be met (AND-ed together).

( Status | Is | Open
  OR
  Status | Is | Pending )
AND
Priority | Is | High
AND
( Tag | Is Present | "escalation_needed"
  OR
  Custom field: Urgency | Is | "Critical" )

The trigger matches a ticket that is either "Open" or "Pending", and has "High" priority, and at the same time has either the tag "escalation_needed" or "Critical" as urgency.

Negation (NOT logic)

It is also possible to test that a condition is not met. This is useful for avoiding loops or targeting specific scenarios.

Ticket is Updated
AND
Tag "follow_up_sent" | Is not Present

This ensures that the action only runs on an update if a specific tag is not already present.

Typical pitfalls and solutions

Even experienced Zendesk administrators can encounter unexpected behaviour. Below are common conflicts and their solutions.

Pitfall 1: Multiple routing triggers in conflict

Problem: A ticket from a VIP customer lands in the general support queue instead of the dedicated VIP queue. Routing appears unreliable and unpredictable.
Cause: A general trigger (e.g. "If form = 'Support' -> Route to 'Support'") is placed above the specific VIP trigger and therefore matches first.
Solution:

Place specific triggers first: Exception rules (VIP, enterprise, escalation) are placed at the top of the trigger list.
Use more specific conditions: Extend the logic with conditions for organisation or a specific tag instead of just checking a form.
Consider consolidation: In some cases, several routing triggers can be combined into one trigger with advanced OR logic.

Pitfall 2: Priority gets overwritten

Problem: A ticket is given "High" priority by one trigger, but is changed shortly after to "Normal" by another.
Cause: Several triggers try to set the priority based on different logic without coordination.
Solution:

Centralise the prioritisation logic: Create one authoritative trigger for priority and place it high in the list.
Use a hierarchical condition structure: Define a ranking, e.g. IF Customer Tier = VIP THEN Priority = Urgent, ELSE IF Product = Critical THEN Priority = High, ELSE IF ...
Disable redundant logic: Identify and disable triggers that also try to set priority.

Pitfall 3: Tag conflicts create chaos

Problem: Tickets end up with conflicting tags such as urgent and low_priority, which makes views and reports hard to use.
Cause: Different triggers add tags based on isolated logic without regard for one another.
Solution:

Document the tag strategy: Create central documentation for the meaning of tags and what adds them.
Avoid conflicting tags: Design the logic so that it is not possible to add both urgent and low_priority. For example, use Tag "low_priority" | Is not Present in the trigger that adds urgent.
Consider custom fields: For complex categorisation (customer type, product, problem area), custom fields are often more robust and scalable than many tags.

Best practices for robust workflows

The following best practices support a maintainable Zendesk setup.

1. Design a hierarchical trigger structure

Triggers can be thought of as a funnel: the most specific and critical rules at the top, the most general at the bottom.

Exception Handling: VIP routing, escalations, blocking spam.
Specific Routing: Routing based on specific forms, products or organisations.
General Routing: Standard routing to the primary support group.
General Actions: Adding standard tags, setting up SLAs, sending notifications.

2. Be specific first

The more specific a trigger is, the higher it should be placed. A trigger that matches on Organization = "SuperCorp" is more specific than one that matches on Form = "Support".

✅ Good order:

Organization | Is | "SuperCorp VIP" → Route to VIP Team
Product | Is | "Enterprise Suite" → Route to Enterprise Team
Form | Is | "Support Request" → Route to General Support
Ticket is Created → Route to Default Queue

❌ Bad order:

Form | Is | "Support Request" → Route to General Support (matches everything)
Organization | Is | "SuperCorp VIP" → Route to VIP Team (does not run, since #1 has already matched)

3. Document everything

Triggers without documentation increase the risk of errors and unpredictable behaviour. For each complex trigger, the following should be documented:

Purpose: Why the trigger exists.
Conditions: Which scenarios are to be matched.
Actions: What should happen when the trigger runs.
Placement: Why the trigger is placed at its specific position in the order.

4. Test edge cases thoroughly

Testing should cover more than the "happy path". Create test tickets to validate:

Combinations: What happens if a VIP customer uses a form for a less important product?
Empty fields: How does the logic react if a required field is empty?
Boundary values: What happens exactly at the boundary of an SLA expiry?

5. Monitor and adjust continuously

The business changes, and the Zendesk setup should be adjusted continuously.

Use the Audit Log: Go to Admin > Activity > Audit Log to see which triggers have run on a specific ticket. This is a central troubleshooting tool.
Analyse data: Review views and reports for patterns, e.g. whether more tickets than expected end up in the wrong group.
Iterate: Adjust, disable or delete triggers that no longer serve a purpose.

The dangerous condition: "Ticket is Updated"

Ticket is Updated is one of the most powerful, but also most risky, conditions. It matches on any update to a ticket: a new comment, a status change, an added tag, the assignment of an agent and so on.

Without care, this condition can create infinite loops.

An example of a classic loop:

Trigger A:
- Condition: Ticket is Updated
- Action: Ticket | Add tag | "updated"
Result: The ticket is updated → Trigger A runs → the tag "updated" is added → this is an update → Trigger A runs again → loop.

The solution is to use negation:

Trigger A (corrected):
- Condition: Ticket is Updated AND Tag "updated" | Is not Present
- Action: Ticket | Add tag | "updated"

The trigger now runs only once. On the next update, the condition Tag "updated" | Is not Present is no longer true, and the trigger is ignored.

The collaboration between triggers and automations

Triggers and automations are often used together in a single flow.

A trigger can prepare an automation: A trigger adds a tag such as awaiting_customer_response on creation. An hour later, an automation checks whether the ticket still has the tag, and if so, sends a reminder.
An automation can fire a trigger: An automation that runs every hour updates a ticket's status to Solved after 7 days of inactivity. The status change can fire a trigger, e.g. a trigger that sends a "satisfaction survey".

The whole chain of events should be considered when designing workflows.

Troubleshooting guide: When the logic fails

When a ticket does not behave as expected, the following approach can be used:

Start with the Audit Log: Find the ticket in Admin > Activity > Audit Log. Here you can see a chronological list of events, including which triggers and automations have run, which conditions matched, and which actions were carried out.
Use a sandbox: If you have access to a sandbox, changes can be tested without affecting the production environment. Create test tickets that match the scenarios being investigated.
Follow the flow step by step: Go through a problematic ticket and clarify:
- What happened on creation, and which trigger matched first?
- Have any manual changes been made that affect the logic?
- Has an automation run later and changed the ticket?
- Is there a trigger further down that should have run but was blocked?

The 3-second rule: A health check for Zendesk

A practical rule of thumb:

If it is not possible to explain why a specific ticket ends up in a particular group with a particular priority and a particular SLA in under 3 seconds, the setup is too complex.

The rule can be used as an indicator of whether the logic has become unmanageable.

Red flags (warning)

❌ More than 20-25 active triggers.
❌ Single triggers with 10+ conditions.
❌ Several triggers carry out conflicting actions.
❌ A lack of central documentation for triggers.
❌ No one on the team can explain the entire flow with certainty.

Green flags (a healthy setup)

✅ A clear, documented and logical order for triggers.
✅ Logic that is easy to explain to new employees.
✅ Tested workflows with known edge cases.
✅ Quick identification of why a ticket has ended up in a particular place.

Strategies for simplification and maintenance

If the setup is in the "red zone", the following measures can be applied.

1. Consolidate similar triggers

Identify triggers that carry out the same or similar actions, and assess whether they can be combined.

Before:

Trigger 1: Form = "Bug Report" → Priority = High
Trigger 2: Form = "System Down" → Priority = High
Trigger 3: Form = "Security Issue" → Priority = High

After (one trigger):

Conditions: (Form = "Bug Report" OR Form = "System Down" OR Form = "Security Issue")
Action: Priority = High

This makes the setup easier to maintain and more performant.

2. Use custom fields instead of complex tags

Tags are flexible, but can become unmanageable. For structured data, custom fields are often better.

Before (complex tag logic):

IF tag "vip" AND tag "enterprise" THEN...
IF tag "premium" AND NOT tag "trial" THEN...

After (simple custom field logic):

IF Custom field "Customer Tier" = "VIP Enterprise" THEN...
IF Custom field "Customer Tier" = "Premium" THEN...

3. Carry out a "trigger audit"

Set aside time to review all active triggers and assess each one:

Is the trigger still necessary?
Are there triggers that are redundant?
Can the logic be made simpler?

The way forward: Optimise the Zendesk setup

Mastering business rules is an ongoing process. By applying the principles in this article, a Zendesk setup can support consistent and effective customer service.

Review existing triggers: Are they necessary, and is the order correct?
Document the logic: Can the flow be explained by the team? If not, documentation should be established.
Test edge cases: Simulate unexpected scenarios to find weaknesses before they affect customers.
Simplify deliberately: A simple setup is often a robust setup; consolidate and clean up continuously.

A controlled and well-structured set of business rules contributes to consistent, efficient and intelligent handling of tickets.