Freshdesk automation rules: how they work and how to set them up (2026)

What "automation rules" actually means in Freshdesk

If you've poked around Freshdesk's admin panel looking for "automations," you've probably noticed the names don't match half the tutorials online. That's because Freshdesk quietly renamed its three classic rule types. The old Dispatch'r, Observer, and Supervisor (or Time Triggers) are gone from the UI. What you'll see today is Ticket Creation, Ticket Updates, and Hourly Triggers, all sitting under Admin > Workflows > Automations, each on its own tab.

The mechanics underneath are unchanged. Every rule is built from conditions (when X is true) and actions (do Y), and Freshdesk's own overview of automation rules confirms there are exactly three types. What changes between them is when the rule gets a chance to run.

This is the layer most people mean when they say "Freshdesk automation rules," and it's separate from two neighbours we'll cover later: scenario automations (manual macros) and automatic ticket assignment. If you want the wider tour of everything automation-related in the platform, our complete Freshdesk automation guide zooms out; this post stays focused on the rules engine itself.

The three types of Freshdesk automation rules

The whole model clicks into place once you stop thinking about what each rule does and start thinking about when it gets to run. Here's the timing at a glance.

1. Ticket Creation rules (formerly Dispatch'r)

These run the moment a ticket is created, which makes them your front door for triage. Per Freshdesk's ticket-creation docs, a creation rule can assign the ticket to a group or agent, set properties like status, priority, and type, fire email notifications, or delete and mark tickets as spam. Conditions can be built on ticket fields, contact properties, or company properties, with AND/OR operators and nested blocks.

There's one setting here that trips up almost everyone. By default, only the first matching rule runs. Freshdesk's own docs warn that "the order of the rules is very important because only the first matching rule will be executed." So if you've got a rule that should fire and it isn't, the usual culprit is a higher rule that matched first and stopped the chain. To change that, click the gear above the rules list and choose "Execute all matching rules."

This is the rule type to reach for when you want new tickets sorted before an agent ever sees them: route billing questions to the finance group, bump anything from a VIP company to high priority, or send an autoresponder acknowledging receipt. It's the closest the classic engine gets to triage, but it can only sort on the fields you tell it to, not on what the ticket is actually about.

2. Ticket Updates rules (formerly Observer)

Where creation rules fire once at the start, ticket-update rules "constantly listen for events you've specified," match them against conditions, and then act. They're the reactive layer: reopen a resolved ticket when a customer replies, assign an agent when a third party adds a note, send a CSAT survey when a ticket is resolved, or email a supervisor on a bad rating from a VIP.

The thing that makes update rules distinct is the event block at the top, which the other two rule types don't have. It has two parts: "when an action is performed by" (agent, requester, either, a collaborator, or the system) and "involves any of these events" (a property changed, a note added, a reply sent, feedback received, plus system events like overdue tickets). Conditions and actions then work as usual underneath.

Unlike creation rules, there's no first-match-only toggle here: "all matching rules are executed from top to bottom." Update rules also carry a Trigger webhook action, which is how you extend Freshdesk out to external systems, the same hook our Freshdesk webhooks guide walks through, and the basis for handy recipes like notifying Slack when sentiment drops. One thing to note: update rules aren't on the Free tier, they start from Growth up.

3. Hourly Triggers (formerly Time Triggers)

The third type handles the passage of time, and Freshdesk's hourly-triggers docs are explicit that this is the feature "FKA Time Triggers." These are the rules that catch what's not happening: tickets sitting unattended, approaching an SLA breach, or resolved-but-not-closed. A classic example is escalating any ticket untouched for 48 hours by bumping priority and pinging a supervisor.

The catch is in the name. Hourly Triggers run once per hour, so any time threshold you set "should always be greater than or equal to one hour." A few more limits worth knowing before you lean on them: they only match against tickets updated in the last 30 days, and they run on ticket properties only, not contact or company properties, and can't use conditions on the email subject, description, requester email, CC, tags, or attachments. If you've ever set up a time-based rule and watched it lag, this is why, and our dedicated Freshdesk time triggers guide digs into the workarounds.

How to set up a Freshdesk automation rule, step by step

Once you know which type you need, the build is the same shape across all three: an optional event, some conditions, and one or more actions.

Here's the walkthrough for a Ticket Creation rule, the one most teams start with:

1. Go to Admin > Workflows > Automations and open the Ticket Creation tab.
2. Click New Rule and give it a name you'll recognise later ("Route billing to Finance" beats "Rule 7").
3. Set your conditions, for example Ticket subject contains "refund" OR Type is "Billing." Use the AND/OR operators and nested blocks for anything more involved.
4. Set your actions: assign to the Finance group, set priority to High, send a notification. You can stack several.
5. Check the execution order. Drag the rule into position, and decide via the gear icon whether you want first-match-only or all-matching behaviour. This single step prevents most "why didn't my rule fire" headaches.
6. Save, then test with a real ticket before trusting it in production.

A few practical habits make this less painful. Freshdesk ships pre-built sample rules (like one that routes refund tickets to a billing group) you can study or clone instead of starting blank, and every rule shows per-rule stats for how many tickets it affected in the last 7 days, which is your quickest sanity check that a rule is actually doing something. There's also no limit on the number of conditions in a rule, so you can get specific, just remember every condition is something you had to think of ahead of time.

The other automation layers: scenarios and routing

The three rule types get most of the attention, but two neighbours do a lot of quiet work, and people often conflate them with automation rules.

Scenario automations are the manual cousin. Instead of firing on conditions, they're one-click bundles of actions an agent runs on a ticket, the macro layer. Rather than tagging a ticket as Refund, assigning it to the Refunds group, and setting status to Processing by hand every time, you bundle those into one Scenario and run it in a single click (or in bulk across selected tickets). They live under Admin > Agent Productivity > Scenario Automations, and you can set whether each one is private, group-wide, or shared with everyone. Our Freshdesk scenarios automation guide goes deeper, but the screenshot below shows the range of actions a scenario can carry.

Automatic ticket assignment is the other one. Powered by Freshdesk's Omniroute engine, it decides who gets a ticket based on agent load, availability, and skills. There are three routing methods: round-robin (circular, capacity-aware), load-based (assigns by how busy each agent is), and skill-based (matches language or product expertise). The important caveat: Advanced Automatic Routing is Pro and Enterprise only, so the fancier auto-assignment options aren't available on cheaper plans.

Which Freshdesk plan do you need for automation rules?

Not every automation is available on every plan, and this is where a lot of "why can't I find this setting" confusion comes from. Here's how the pieces line up across Freshdesk's pricing tiers. (Numbers reflect the standalone Freshdesk plans; the prices are annual, per agent.)

The headline: basic creation-time triage is free, but anything reactive, time-based, or load-aware needs at least the Growth plan, and the smartest routing is gated to Pro and Enterprise. If you're weighing whether the jump is worth it, our Freshdesk plans comparison and honest Freshdesk review both get into the trade-offs.

Where Freshdesk automation rules hit a wall

Automation rules are good at exactly one thing: doing what you told them to, when the conditions you wrote are true. That's also their ceiling. Every rule is a guess you made in advance about what tickets will look like, and tickets rarely cooperate.

Three walls show up again and again:

• Rules match on conditions, not on meaning. A creation rule can route a ticket whose subject contains "refund," but a customer who writes "I want my money back" sails straight past it. You end up maintaining ever-longer keyword lists, and you're always one phrasing away from a miss.
• Time-based logic is coarse. Hourly Triggers only wake up once an hour, so "escalate if no reply in 30 minutes" simply isn't expressible. For fast-moving queues, an hour is an eternity.
• They can't actually answer anything. Rules can route, tag, set priority, and prefill a canned response, but they can't read a question and write the real reply. That work still lands on a human.

We've felt this from the deal side too. In one evaluation, a Freshdesk customer couldn't get a new automation rule to coexist with their existing rule stack, the rules kept fighting over execution order, and they were repeatedly steered back toward Freshdesk's own Freddy AI when they asked support for help. The friction wasn't that rules are bad; it's that stacking more and more if-then logic to approximate understanding eventually collapses under its own weight. This is the same gap our Freshdesk AI auto-triage and tag-by-intent write-ups keep circling: the moment you want the system to understand the ticket rather than match a field, you've outgrown the rules engine.

Try eesel for the tickets rules can't reach

If you've read this far, you probably already have your routing rules dialed in and you're staring at the pile of tickets they can't close. That's the gap eesel AI was built for. It sits on top of your existing Freshdesk (and Slack, email, Shopify, and 100+ other tools), learns from your past tickets and help docs in minutes, and reads what each customer actually meant, so it can draft or fully resolve replies that keyword-matching rules never could.

The part that matters next to Freshdesk's rules: you stay in control of which tickets the AI touches. Instead of an all-or-nothing switch, you scope it by ticket type or confidence, so it handles the repetitive questions and leaves the edge cases for your team, the "we won't let AI auto-reply to everything" worry that stalls most rollouts. It bills at a flat $0.40 per resolution with no per-seat fees and a spend cap you set, and because it layers on top rather than replacing Freshdesk, there's no migration to schedule.

You can start with a $50 credit and no card, point it at your real tickets, and watch what it handles before you spend a cent. Try eesel and keep the Freshdesk rules you've already built, eesel just covers everything they can't.