Support routing and automation

Support routing sends each request to the team that can act on it. Automation can decide this at intake, respond to a later change, or flag unclaimed work. Start with reliable ticket data, a visible owner and a monitored path for cases the rules cannot classify.

Decide what each rule must do

For each common request, record the fields available on arrival, the receiving group and who checks that group for unassigned work. Sending a ticket to a group does not mean an agent has accepted it. If a field is missing or conflicts with the request, send the case to a monitored triage queue for clarification.

Keep the decisions separate:

Prepare the intake rules

Before you create Freshdesk ticket-creation automations, confirm the required groups, agents, tags, custom fields and email addresses exist. The administrator needs access to Admin > Workflows > Automations. Define the routing, notification and field-update requirements for new tickets.

Freshdesk creation rules can evaluate ticket fields and properties, requester or contact fields, and requester company properties. They can assign tickets to groups or agents, update ticket properties, send notifications, mark tickets as spam, close or delete tickets, and trigger webhooks. Use conditions based on information available at creation; data populated later needs a separate update or time-based mechanism.

Choose how work reaches an agent

Zendesk supports push routing, which assigns tickets to agents, and pull routing, where agents choose their own work. Both can combine with standard views and triggers, which provide a basic framework without further configuration.

In a newly registered Zendesk account, support requests sent by email or another channel become tickets. Standard views include Your unsolved tickets, All unsolved tickets and Recently updated tickets. Standard triggers notify the requester and CCs, and notify agents when a ticket is created or updated. Check which existing view or notification covers each event before adding another routing action.

Push vs Pull Routing: Pros and Cons

Match the rule to the event

Zendesk ticket triggers run when tickets are created or updated; its time-based automations run hourly. Freshdesk has separate creation, update and hourly rules, and a creation rule cannot correct a classification made after intake. Freshdesk creation rules can run only the first match or all matches, so order and overlapping actions matter. Check the configured account before using a rule pattern from another product.

Time-based alerts need a clear stopping condition. Zendesk requires an automation to change a qualifying condition or use one true only once. An open-ended time condition may act on successive hourly runs, so validate that repeated actions are controlled. An alert should lead to an accepted next action, and the unassigned queue should stay visible for cases an alert misses.

Check which event can use each condition

Freshdesk hourly automations evaluate ticket properties and time-based conditions, such as hours since an agent responded or since a first response was due. They cannot use contact or company properties, or conditions such as email subject, description, requester email, CC, tags or ticket forms. Keep these distinctions in the rule specification so an intake condition is not assigned to an hourly rule by mistake.

Freshdesk hourly rules run against tickets each hour when their conditions match. A rule can assign a ticket to an agent or group, or email them after a defined time since the customer responded. Decide what action follows the time condition, and check that a later hourly run will not repeat an alert without a corresponding state change.

Freshdesk vs Zendesk: Automation Rule Capabilities

Govern rule order and repeated actions

Freshdesk creation rules can run the first matching enabled rule, the default, or every matching enabled rule. With first-match execution, place specific rules above generic ones. With all-match execution, check overlapping conditions for conflicting assignments, field updates or notifications.

Zendesk automations run hourly on non-closed tickets and can fire on a maximum of 1,000 tickets per hour. Each ticket can be updated at most 100 times by automations, except the Close ticket automation can still fire after that limit. Zendesk also allows a maximum of 500 active automations. Treat these limits as part of the review when changes affect a large set of tickets.

Review messages and exceptions

List the default notifications and workflow emails for each customer-facing event before adding another. Zendesk identifies multiple triggers on one update as a common cause of duplicate emails. Where a creation rule sends email, check whether a separate notification also covers the event. Review the resulting messages and recipients, not just the rule names.

Keep a short record of each rule's purpose, owner, conditions, actions and exception path. Review tickets that repeatedly move between groups: the cause may be incomplete intake information, overlapping rules or an unclear team boundary.

When investigating a duplicate Zendesk email, review the ticket events. Identify repeated Email notification events under the ticket comment, then follow each event to its trigger. Before deactivating a duplicate, verify it is not a default trigger required for customer notifications. Check notification settings alongside automation actions before changing either.

Pre-Implementation Checklist for Support Routing Rules

Check the ticket path

For a proposed change, write expected results for an ordinary ticket, a missing field, a conflicting field and a later correction. Use safe sample details, then inspect the final group, assignee, event history and outgoing messages. A sandbox can help where available, but its copied settings and integrations may differ from production. Widen a change only after the receiving team can act on the cases and uncertain work remains visible.

Validate the configured outcomes

For Freshdesk creation rules, test both the intended match and a ticket that does not meet the conditions. Confirm the selected execution mode and rule order, then inspect whether each matching rule performed only its intended actions. If rules send email, compare the result with the existing requester notification settings.

Zendesk sandbox availability depends on the plan: Support Enterprise includes one sandbox, while Suite Enterprise and Enterprise Plus include two. Sandboxes can help test workflow changes, but Zendesk notes that some replicated items, including webhooks, are set to inactive by default. Check the sandbox creation report to see what was successfully replicated before treating a test result as representative of production.