[object Object]

Conditions

Subject, description, email address, channel, requester company, and any custom field can drive a dispatcher rule. Logic supports AND/OR grouping with up to 10 condition rows per rule (the practical UI cap before the rule becomes unreadable). Match specificity matters because the dispatcher only fires once per inbound ticket — at creation. A condition like From email contains @vip.com AND Subject contains "outage" is far better than Subject contains "outage" alone, because the second rule will collide with every other “outage” rule in the chain. Use the “any of these” multi-value mode for keyword lists rather than chaining 10 separate OR rows.

Actions

Common actions: assign group or specific agent, set priority (Low/Medium/High/Urgent), apply tags, add a watcher, send an auto-reply using a canned response template, update custom fields, and skip notification (useful for spam quarantine). Less obvious but worth knowing: the “Mark as spam” action permanently removes the ticket from queues, and “Delete the ticket” is irreversible — always pair these with a tag like auto_filtered_yyyy_mm so audits can find what got dropped. Mark group assignments before agent assignments so round-robin inside the group still works if your agent action falls through.

Rule Ordering

Rules execute top-down, and “first match wins” only applies when you check the per-rule “stop processing further rules” toggle (it is off by default in Freshdesk). Without that toggle, all matching rules fire in sequence — which is why you see priority bumped twice or a ticket assigned then reassigned. The fix is simple but counterintuitive: enable “stop on match” on every specific rule and leave it off only on the broad fallback rule that handles “everything else.”

Testing

Create test tickets that hit each rule’s exact criteria. The Freshdesk UI lets you create a ticket from inside admin without leaving the rule editor — use it. Better, write a small FDK or curl script that posts to /api/v2/tickets with controlled payloads:

const payload = {
  email: '[email protected]',
  subject: 'outage in production',
  description: 'service down',
  status: 2,
  priority: 1
};
fetch(`https://${domain}.freshdesk.com/api/v2/tickets`, {
  method: 'POST',
  headers: {
    Authorization: 'Basic ' + btoa(`${apiKey}:X`),
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(payload)
});

Run the script after every batch of rule changes and grep the resulting tickets by tag to confirm the right rules fired.

Governance

Rule count grows fast — most tenants pass 50 rules within a year. Prefix rule names with two-digit ordering keys (01_VIP_outage, 02_VIP_billing, 90_fallback_round_robin) so the visual order in the UI matches execution order. Quarterly audits should answer four questions: which rules fired zero times, which rules fired more than expected, which rules contain conditions referencing retired fields, and which rules duplicate logic that could collapse into one.

Common Failure Modes

The classic dispatcher bug: a rule references a custom field that an admin renamed, and Freshdesk silently disables the rule rather than warning. Subscribe to the daily admin audit email and grep for “rule disabled.” A second classic: business hours change for daylight saving and a rule that relies on Created at time-of-day starts misfiring for two weeks until someone notices. Document business-hour-dependent rules separately so they’re easy to revisit.

What to do this week

Export your current rule set (Admin -> Workflows -> Dispatch’r -> Export), open it in a spreadsheet, sort by last-fired-date, and disable any rule that hasn’t fired in 90 days. Cleanup-by-deletion is reversible from version history; cleanup-by-disable is reversible with one click.

[object Object]
Share