Dispatcher: Inbound Routing
Routes incoming tickets based on conditions (subject keywords, sender domain, product, source channel) at the moment of creation. Runs once per ticket, never re-evaluates. This is the right place for first-assignment logic, initial priority setting, and tagging that downstream rules depend on. Common pattern: dispatcher tags the ticket with tier_1, tier_2, or tier_3 based on customer-tier custom fields, and observer rules later branch on those tags. Keep dispatcher actions idempotent — a misrouted ticket can be reassigned manually, but a dispatcher-applied auto-reply cannot be unsent.
Observer: Post-Update
Triggers on ticket changes — status updated, priority bumped, reply added, custom field changed, agent assigned. Used for SLA escalations, satisfaction follow-ups, manager notifications, and conditional handoffs (priority bumped to Urgent → notify on-call). Observer rules can fire repeatedly on the same ticket as it moves through stages, so guard with conditions like status changed FROM Pending TO Open rather than status IS Open. The latter fires every time anyone touches an Open ticket.
Supervisor: Time-Based
Runs hourly across all tickets matching its conditions. Useful for “tickets open more than 24 hours and untouched” — escalate, “tickets resolved more than 7 days” — auto-close, or “tickets pending customer response more than 14 days” — send reminder then close. Supervisor is the only engine that can act on the absence of activity. Time conditions respect business hours when the ticket has an SLA attached, and use 24/7 wall-clock when not.
// Equivalent supervisor query via API
fetch(`https://${domain}.freshdesk.com/api/v2/search/tickets?query="status:2 AND updated_at:<'2026-04-23T00:00:00Z'"`, {
headers: { Authorization: auth }
});Scenarios
One-click agent actions — categorize, assign group, reply with template, set priority. Manual but speeds repetitive work. The right pattern: build scenarios for the top 10 ticket types your agents handle and bind them to keyboard shortcuts. A senior agent who used to take 90 seconds to triage now takes 5. Scenarios also enforce consistency in canned replies because the template is centrally managed.
Governance
Document every rule with a description field that explains why it exists and who owns it. Disable rather than delete — Freshdesk version history is shallow and a deleted rule is gone. Review quarterly because dispatcher spaghetti compounds: every team adds a rule for their use case, no one prunes, and after a year a single ticket can pass through six observers and have its priority bumped twice. Tag rules with prefixes (SLA_, VIP_, BILLING_) so the admin search filters cleanly.
Common Failure Modes
The classic: an observer rule sets priority to High, which triggers another observer that sends a Slack alert, which triggers a supervisor that re-escalates, which triggers an observer that resets priority. Build a simple test harness — create a test ticket in a sandbox, watch the activity log, count rule firings. Anything firing more than three rules per touch needs flattening. Second classic: SLA paused/unpaused state isn’t visible to most automations; build separate observer rules to handle the pause_started and pause_ended activity entries explicitly.
Implementation Sequence
Map the desired ticket lifecycle on a whiteboard before writing rules. Identify the four to six state transitions that matter (new -> assigned, assigned -> in progress, customer response received, resolved, closed). Build dispatcher rules for state 0, observer rules for transitions 1-4, supervisor rules for stuck-in-state catches, and scenarios for the manual actions agents take dozens of times per day. In that order.
What to do this week
Pull the rule activity report (Admin -> Workflows -> Activity Log) and identify any rule that fired zero times in the last 30 days. Disable it. The fastest cleanup is the deletion of dead code — rules are no different.
