Admin Pro Tip: Automations - Power User vs. Power Failure

In Zendesk, automations are a key tool for creating a more self-running support setup, where tickets are routed, prioritised and handled with minimal manual effort. A well-functioning automation is typically invisible, efficient and reduces both clicks and manual errors. There is, however, a fine line between an elegant setup and a complex, unpredictable system that no one wants to touch.
The dividing line is complexity. It is often the case that an administrator with good intentions builds a "super automation" that tries to handle everything from the customer's VIP status to which month the ticket was created in. At first it works well, but once the exceptions start to appear, the automation quickly turns into a labyrinth of conditions, "if-then-else" logic and tags that only the original author can decode. When that person is absent or leaves the organisation, you are left with a black box that can start behaving unpredictably.

This article brings together key lessons, best practices and concrete advice for building, testing and maintaining automations that create value rather than operational pain.

When automations become too complex

When does an automation go from being clever to being risky? It is less about the number of conditions and more about the transparency of the logic and the ongoing maintenance burden. Complexity typically arises when an automation tries to solve too many tasks, or when the logic depends on too many hidden variables.

Signs of an over-complex automation

• More than 5-7 conditions: Although Zendesk technically allows more, it is often a sign that the logic should be split up. When you have to scroll to see all the conditions, the overview quickly suffers.
• Dependence on obscure custom fields: An automation that only works because a specific custom field with a cryptic name like cf_internal_prio_2b is set to "Yes" is fragile. If a new agent does not know what the field means, the automation can stop working as intended.
• Logic that exists only in one person's head: If a flowchart is required to explain the automation, it is typically too complex. The logic should be readable linearly from top to bottom.
• Constant exceptions: If new edge cases that require yet another "OR" condition are continually being discovered, it is often a sign that the underlying assumption is wrong, and that the automation should be split into several, more specialised rules.

A practical example: "The Super Router"

Imagine an automation that is meant to assign tickets and that looks like this (simplified):

Conditions:

• Ticket | Status | Is | New
• Ticket | Content | Contains | "urgent"
• Ticket | Content | Contains | "VIP customer"
• Ticket | Company | Is | "ACME Corp"
• Ticket | Custom field | Customer type | Is | "Enterprise"
• Ticket | Via | Is | "Web form"
• Ticket | Subject | Contains | "Invoice"

Actions:

• Add tags: haster, vip, enterprise, faktura
• Change priority to High
• Assign to "Specialist team"
• Notification to the Slack channel #critical-alerts

The challenge is that the combinations quickly become unmanageable: What if a VIP customer sends an urgent ticket about an invoice by email? What if an Enterprise customer who is not a VIP sends a non-urgent request? The logic quickly becomes a large number of "if-then-else" scenarios.

A better approach: Split the logic

1. Automation 1 (Tagging): Runs once to add relevant tags based on words and customer type. IF "VIP customer" OR Company = "ACME Corp" THEN Add tag: vip.
2. Automation 2 (Prioritisation): Runs slightly later. IF Tag: haster OR Tag: vip SET Priority to High.
3. Trigger (Routing): Uses tags to route the ticket to the correct team. IF Ticket is Created AND Tag: vip THEN Assign to "Specialist team".

When each rule has a single responsibility, troubleshooting and maintenance become easier, and new administrators can understand the relationships more quickly.

Sandbox testing: Avoid errors in production

Building automations directly in the production environment involves high risk. A sandbox acts as a safe environment in which to experiment, fail and adjust without affecting customers and agents.

There should be a consistent practice: No new or significantly changed automation is put into production before it has been thoroughly tested in the sandbox.

A systematic approach to sandbox testing

A good test is a disciplined process, not simply "trying it out".

Step 1: Clone reality

The sandbox is most useful when it mirrors production. Before testing, the relevant elements should be in place:

• Users and organisations: Export a list of key users, VIP customers and agent groups, and create them in the sandbox. Make sure you have a mix of user types (end user, agent, admin).
• Custom fields: All custom fields that the automation interacts with must exist in the sandbox with the same dropdown values.
• Macros and views: If the automation is meant to work together with a macro (e.g. by setting a tag that a macro reacts to), the macro must also be present.
• Other related automations/triggers: If the new automation is meant to run after a trigger, the trigger must also be active and tested in the sandbox.

Step 2: Define test cases (the most important step)

You need to think like someone who is trying to break the automation. Create a checklist with both positive and negative scenarios.

Test Case ID	Description	Expected result	Actual result	Status
TC-01	New ticket from VIP customer via web form	Ticket gets tag vip, priority High, assigned to Team A
TC-02	New ticket from ordinary customer via email	No changes from this automation
TC-03	New ticket with the word "urgent" in the subject	Ticket gets tag haster, priority High
TC-04	New ticket from VIP customer with "urgent" in the subject	Ticket gets tags vip and haster, priority High, assigned to Team A
TC-05	New ticket, but custom field "Customer type" is empty	The automation does not run, because a condition is not met
TC-06	Ticket updated by agent 1 hour after creation	Nothing happens (the automation only runs on "New" status)
TC-07	New ticket from a user who has been deleted in the system (edge case)	The automation fails gracefully or ignores the ticket

Go through each item, observe the result in the sandbox, and note it in the table. If the "Actual result" does not match the "Expected result", an error has been identified before it reaches production.

Step 3: Test "what if" scenarios

Extend the tests beyond the standard cases:

• What if an agent manually changes the priority right after the automation has set it? Should another automation set it back?
• What if a required condition, e.g. a custom field, is missing? Should the automation fail silently, or should a notification be sent to an admin?
• What if two opposing automations are active at the same time? (see the section on common errors).

Step 4: Document and approve

Once all test cases are green, the automation's purpose, rationale and ownership should be documented. A colleague or team leader should review the test-case table and the logic as an approval step. An extra set of eyes often catches errors that are missed.

Only after this can the automation be replicated in production, condition by condition and action by action.

Debugging automations that do not work

Even with careful testing, an automation that has worked for months can suddenly fail. A ticket that should have been assigned ends up "Unassigned". A systematic approach reduces the risk of troubleshooting that creates new problems.

The systematic troubleshooting process

1. Start with the basics (the simple checks):

   • Is it active? Is "Active" turned on? A change can unintentionally deactivate an automation.
   • Check the run time: Does it run "When ticket is created", "When ticket is updated" or on a schedule (e.g. "Hourly")? It may be set to run at a different time than expected.
   • Execution Log: Go to Admin > Automations and click "Executions" for the relevant automation. Here you can see the most recent run and the number of tickets processed. If it says "0 tickets matched", that points to the conditions.

2. Isolate the problem with Ticket Inspector:

   • Find a specific ticket that should have matched the automation but did not.
   • Open the ticket and use "Ticket Inspector" (or the three dots > "Apps" > "Ticket Inspector", if available). The tool shows the exact state of fields, tags and values at the relevant time.
   • Go through the conditions one by one and compare them with Ticket Inspector:
     • Condition: Ticket | Status | Is | New. Inspector shows: Status: Open. A trigger or another automation changed the status before the automation had a chance to run.
     • Condition: Ticket | Custom field | Customer type | Is | "Enterprise". Inspector shows: Customer type: (blank). The field was not filled in.

3. The "comment out" method:
   With many conditions, the culprit can be hard to find. Edit the automation:

   • Disable the bottom half of the conditions.
   • Save and test with a new ticket in the sandbox (or wait for the next ticket, if necessary).
   • If it now runs, the error lies in the part that was disabled.
   • Repeat by disabling half of the remaining conditions, until the specific condition has been isolated.

4. Check for "race conditions":
   Zendesk has a fixed order: Webhooks -> Triggers -> Automations.

   • A trigger runs immediately when a ticket is created or updated.
   • An automation runs with a delay (typically 5-10 minutes) on a schedule.
   • Problem: A trigger can change the ticket so that the automation's conditions are no longer met.
   • Example:
     • Automation: IF Status is New AND Tag: vip SET Priority to High.
     • Trigger: IF Ticket is Created SET Status to Open.
     • Result: The trigger runs first and sets the status to "Open". Later the automation runs, sees that the status is not "New", and does nothing.
   • Solution: Adjust the condition to IF Status is less than Solved AND Tag: vip... or move the logic to a trigger instead.

Fallback strategies when automations fail

Even well-designed and tested automations can fail, e.g. due to downtime, changes in Zendesk or unforeseen workflows. A robust setup includes safety nets.

Proactive fallbacks: An early warning system

The strategies here are designed to catch errors before they become big.

• "Safety Net" views: Create views that catch tickets that "fall through the cracks".

  • Example 1 (Unassigned Tickets): Status < Solved, Assigned: (unassigned), Updated more than 1 hour ago. Catches tickets that should have been assigned by routing but were not.
  • Example 2 (SLA Breach Imminent): Status: New, Open, Pending, SLA: Breached within 1 hour. Catches tickets where the SLA automation may have failed.
  • Example 3 (Stuck in a Loop): Status: Pending, Updated by: (a specific webhook user), Updates: > 10. May indicate a loop between webhook and automation.

• Notifications on safety nets: A view only has value if someone reacts to it.

  • Use a trigger: IF Ticket is updated AND Ticket is in "Safety Net" view THEN Send email to "admin-team@company.dk".
  • Use an app such as "Observe" or integrate with Slack, so that a message is sent when a ticket lands in a safety-net view.

Reactive fallbacks: An emergency plan

If an automation has failed over a longer period (e.g. over a weekend), a plan for cleanup is needed.

• A predefined "Bulk Action" plan: Have a written procedure for manual remediation.

  • Example: "The routing automation failed from Friday at 17:00 to Sunday at 20:00.
    1. Go to the view 'Unassigned Tickets - Weekend Failure'.
    2. Filter on tickets created in the relevant period.
    3. Select all tickets.
    4. Apply the macro 'Bulk Assign - Post Mortem', which assigns tickets based on brand and language.
    5. Apply the macro 'Bulk SLA Set - Post Mortem', which sets the correct SLA target."
  • A fixed plan reduces panic and inconsistent manual fixes.

• Manual override as a deliberate design choice: Agents must be able to perform the actions that automations normally perform. If an automation assigns a ticket, teams must be visible, and manual assignment must be possible. If an automation sets priority, the priority must be changeable. A setup should not be so locked down that a single error paralyses the workflow.

Common automation errors and how to avoid them

The same types of error often recur. Below are typical pitfalls and ways to avoid them.

Error 1: "Execution Limbo" - incorrect condition logic

Problem: The wrong choice is made between "Check all conditions" and "Check any condition", which can cause an automation either never to run or to run on everything.

• Example: An automation should run if a ticket is either from a VIP customer OR has the word "urgent" in the subject. If you do not switch to "Check any condition", the automation only runs if the ticket is from a VIP customer AND has "urgent" in the subject.
• How to avoid it: Read the condition logic aloud before saving: "Run IF A AND B AND C ..." or "Run IF A OR B OR C ...".

Error 2: "The Race Condition" - automations that work against each other

Problem: Two automations (or a trigger and an automation) have conflicting goals and "fight" over the same ticket.

• Example:
  • Automation A: IF Tag: vip SET Priority to High.
  • Automation B: IF Company: "Standard Corp" SET Priority to Normal.
  • A VIP customer from "Standard Corp" writes in. Automation A sets the priority to High. Later, Automation B runs and sets it back to Normal.
• How to avoid it: Be aware of the order and control it via tags. Automation A can add the tag prio_set_by_vip. Automation B can add the condition: ... AND Tag: prio_set_by_vip | Is not | present.

Error 3: "The Update Trap" - an infinite loop

Problem: An automation updates a ticket, which triggers a trigger, which in turn causes the automation to run again, repeatedly.

• Example:
  • Automation: IF Status is New AND Updated more than 60 minutes ago SET Status to Open AND Add tag: auto_stale.
  • Trigger: IF Ticket is updated AND Tag: auto_stale is present THEN Send internal notification.
  • When the automation adds auto_stale, that is an update which can trigger the trigger. Depending on the conditions, it can also cause repeated automation runs.
• How to avoid it: Use "stop-the-loop" logic by adding a tag that the automation itself checks:
  • Corrected automation: IF Status is New AND Updated more than 60 minutes ago AND Tag: auto_stale | Is not | present SET Status to Open AND Add tag: auto_stale.
  • Once the tag is set, the automation does not run again on the same ticket.

Error 4: "Time Zone Troubles"

Problem: Time-based conditions in automations run in the Zendesk account's time zone, not in the individual agent's or customer's time zone.

• Example: A team in Denmark (GMT+1) and a team in the USA (GMT-7). An automation: IF Ticket is created after 17:00 SET Assignee to "Night shift". For the US team, 17:00 is the middle of the day, but for the system it is evening, and tickets are routed incorrectly.
• How to avoid it: Be explicit in the conditions. Avoid times across teams where possible. Use tags or other markers that agents can set instead, or base it on "business hours", which can be configured per schedule.

Red flags: automations no one can explain

These are the most risky automations, because they are also an organisational problem: knowledge is locked to one person or has been lost over time.

Red flag 1: "It has always been that way"

An experienced agent cannot explain why tickets from "XYZ Inc" are automatically assigned to "Team B" and get the tag legacy_process, and refrains from changing anything for fear of breaking the system.

This typically indicates a missing owner, missing documentation and no current business rationale. It is often a remnant of an earlier process.

Action: Set a "sunset" date. Temporarily deactivate it during a low-traffic period (e.g. a weekend) and observe the consequences. If nothing is affected, the automation can be deleted. If something is affected, the purpose has been identified and can be documented, after which a better version can be built.

Red flag 2: The secret setup

One person has built all the complex automations, and no one else dares to change them. When problems arise, only this person can solve them.

This represents a significant business risk in the event of illness, holiday or resignation.

Action: Knowledge sharing must be part of operations. Carry out an "automation audit", where each automation is reviewed with another admin or team leader. Document it in a shared document (Confluence, Notion, Google Docs) with:

• Purpose
• Owner
• Conditions (in plain language)
• Actions (in plain language)
• Related automations/triggers

Red flag 3: Constant tweaking

An automation requires new exceptions or new "if-then" clauses every other week.

This is often a sign of a wrong underlying assumption. Instead of more patches, you should assess whether the automation should exist in its current form, or whether it should be split up.

Action: Go back to the starting point and identify the underlying need behind the exceptions. Often the solution is two or three smaller, specialised automations instead of one big one.

Green flags: a simple and tested automation setup

A healthy setup typically has the following characteristics.

Green flag 1: Owner and documentation

Each automation has a named owner (a person, not just "the Admin team") and a short, precise description of its purpose, written so that a new agent can understand it.

Example description: "Owner: [Name]. Purpose: Sets the SLA target to 'First Reply - 8 hours' for all new tickets from enterprise customers, so that they are captured by SLA measurements."

Green flag 2: The Single Responsibility Principle

Each automation performs one task: assignment, prioritisation or notification. It does not try to solve several purposes at once. This makes testing, troubleshooting and maintenance easier.

Green flag 3: Predictable names and tags

A clear and consistent naming convention is used:

• Automations: auto_routing_, auto_sla_, auto_cleanup_
• Triggers: trigger_notify_, trigger_tag_
• Tags: vip_customer, high_priority, needs_followup, billing_issue

When a tag or an automation is seen, its purpose is clear without opening the logic.

Green flag 4: Integration into onboarding

New agents receive an introduction to the 5-10 most important automations and triggers that affect daily operations. For example: When a ticket is assigned to "Billing", an automation runs that notifies accounting, which explains why a manual email is not necessary.

Green flag 5: Regular cleanup (automation audit)

There is a fixed, quarterly "Automation Audit" in the calendar, where active automations are reviewed with a focus on:

• Whether they are still relevant
• Whether deactivated automations can be deleted
• Whether any have become too complex and should be split up
• Whether any lack an owner and need to be assigned

This reduces digital clutter and helps keep the setup efficient and predictable.

Conclusion: From Power Failure to Power User

Mastering Zendesk automations is not about building the most complex rules, but about building the most reliable and predictable ones. The strength lies in simplicity, clarity and robustness.

With sandbox testing, safety nets, systematic troubleshooting and a focus on transparency, automations can be developed from a potential "Power Failure" into a stable, valuable engine in the support organisation. The goal is a setup that works consistently in everyday operations and supports agents in delivering high-quality customer service.