## TL;DR
Dispatcher recursion happens when a rule's action modifies the ticket in a way that re-satisfies the rule's own conditions. Break it with a guard: a condition the action makes false, such as a status change or a marker field the rule excludes. Pause the rule first, because every cycle while you diagnose adds to the mess.

## The query

```text
freshdesk "dispatcher rule recursion" infinite ticket updates
```

## Use this when

- Ticket histories show rapid repeated updates
- A dispatcher rule fires continuously on the same ticket
- Ticket update counts spiral
- You are debugging dispatcher behavior

## Not for

- Creating dispatcher rules
- Designing ticket fields
- Agent notification rules
- One-off duplicate updates

## Steps

### 1. Pause the recursing rule immediately

Disable the rule before diagnosing. Each cycle writes more history and may trigger webhooks, notifications, and SLA recalculations. Pausing is safe; the queue will wait.

Expected output: rule paused, update storm stopped.

### 2. Find the self-triggering condition

Read the rule: which conditions does its own action re-satisfy? Typically the rule sets a field that its conditions match, or updates the ticket in a way that re-qualifies it. Map the exact loop.

Expected output: the condition-action cycle named.

### 3. Add a guard the action makes false

Change the action to move the ticket out of the rule's conditions: set a status the rule excludes, set a marker field, or add a tag the rule filters on. The rule must not match its own output.

Expected output: rule conditions exclude the rule's own output state.

### 4. Check for rule-to-rule ping-pong

Two rules can recurse through each other: rule A sets what rule B matches, and B sets what A matches. Review all rules touching the same fields, not just the obvious one. Guards must cover the pair.

Expected output: related rules reviewed, pair recursion guarded.

### 5. Re-enable and monitor one ticket

Turn the rule back on and watch a single ticket flow through it. Confirm it fires once. Then monitor rule execution counts for an hour for recurrence.

Expected output: single fire per ticket, execution counts stable.

## Template: the checklist

```text
Dispatcher recursion:
[ ] Recursing rule paused
[ ] Self-triggering condition-action cycle mapped
[ ] Guard added: action moves ticket out of rule conditions
[ ] Related rules checked for ping-pong
[ ] Rule re-enabled, one ticket watched, counts monitored
```

## Variant phrasings

### freshdesk rule firing repeatedly

Steps 1 and 2. Pause, then map the cycle.

### dispatcher updating ticket in loop

Steps 3 and 4. Guard the rule, check its neighbors.

### freshdesk infinite ticket updates

Full sequence as the recovery runbook.

## Why it happens

Dispatcher rules evaluate on ticket events including updates, and rule actions are updates. Without a guard, a rule whose action re-satisfies its conditions is a feedback loop by construction. It usually starts when someone edits a working rule's action without re-checking its conditions.

## Edge cases

- Time-based rules: "updated more than X hours ago" conditions re-arm themselves over time. Exclude the action's output state explicitly.
- Bulk operations: a bulk update can re-qualify thousands of tickets at once, turning a slow recursion into a storm. Pause rules during bulk jobs.
- Webhook-triggered updates: the rule fires, the webhook updates, the update re-fires the rule. Guard both sides.
- Rule execution order: order changes which rule sees the ticket first. Document the intended order.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vu-Ry_uIAxRRddDlElMg3Q