Preventing infinite loops in triggers

A trigger whose action satisfies its own conditions runs again. Zendesk stops it eventually, after the damage.

A trigger whose action satisfies its own conditions runs again. Zendesk stops it eventually, after the damage.

How a loop happens

A trigger's action counts as an update, and an update runs the triggers. So a rule that fires when priority is high and sets priority to high fires again on the update it just caused.

Two rules can do it between them, which is harder to spot: one sets a tag, the other reacts to the tag and changes a field the first watches.

What it looks like

• A ticket with dozens of identical events seconds apart.
• A customer receiving the same email repeatedly.
• Your API usage rising sharply for no obvious reason.

Zendesk detects and stops runaway loops, but not before a customer has had ten copies of the same message.

The three defences

Use changed to, not is

A rule firing on a transition cannot fire again on the update it caused, because the transition already happened. This alone prevents most loops.

Exclude your own change

Add a condition on current user, or a tag the rule sets and then requires the absence of. Either makes the rule unable to react to itself.

Do not set what you test

The simplest discipline. If a trigger's condition and action touch the same field, look at it twice.

See also

• Building conditions: all, any, and the trap in between
• What a mail loop is and how Zendesk prevents it
• Making sure an automation runs only once