Configuration

Automations

An automation is a “when X, then Y” rule. There are two families — rules that fire on an event, and rules the worker sweeps on a clock — and the order they run in changes the result.

Two families of rules

Trigger rules run the moment something happens to a ticket. Three events fire them: Ticket created, Ticket updated and Message received (a reply from the contact). The rule is evaluated against that single ticket, on the spot.

Scheduled rules are swept by the worker every five minutes across your open and recently-solved tickets. They match on time — the Hours since creation and Hours since update fields — so they are how you chase, escalate or close a ticket that has simply gone quiet.

You pick the family when you create the rule; the editor states which one you are in. Both families live in the same list and share the same conditions and actions.

Conditions and actions

A rule matches when all of its conditions hold (you can also add an “at least one of” group). Conditions read a field with an operator: Status, Priority, Channel, Type, Subject (contains), Tags (includes), Assignee, Team, Organisation, Event, and the two numeric age fields compared with ≥ / ≤.

The actions a rule can apply are fixed:

  • Set the status
  • Set the priority
  • Assign to an agent
  • Assign to a team
  • Assign to the next agent (round-robin) — the least-loaded active agent on the ticket's team
  • Add tags
  • Send an email to the contact

The editor has a live Test on an existing ticket: it runs your draft conditions against your most recent ticket and tells you whether the rule would apply and what it would do — without writing anything.

The rule editor: the IF block of conditions, the THEN block of actions, and the Test on an existing ticket panel.
Figure 10. The rule editor: the IF block of conditions, the THEN block of actions, and the Test on an existing ticket panel.

The order rules run in

Rules run top to bottom, in the order shown in the list. On an event, every active trigger rule is evaluated in one pass, and each matching rule applies its actions to the ticket as the rules before it left it — so a rule that sets the priority early is seen by a later rule that reads the priority. Use the up and down arrows to reorder.

When a ticket is created, trigger rules run before the SLA is assigned. A rule that raises the priority therefore changes which SLA target the ticket gets.

Keeping a rule from looping

Within a single event no loop is possible: the engine reads the rule list once, and an action never re-enters the engine. The trap is on the other side — a scheduled rule is re-evaluated over the same tickets every five minutes.

A scheduled rule whose action leaves its own condition true fires again on every sweep. The classic case: a rule that only sends an email does not change the ticket, so Hours since update never resets — the contact is emailed again every five minutes, and the ticket thread and run log fill up. This will not stop on its own.

To make a scheduled rule self-terminating, either:

  • have the action change a field the condition reads — set the status or the priority so the condition no longer matches next time; or
  • pair a “quiet” action (send an email) with one that writes to the ticket (add a tag), so the update touches the ticket and Hours since update resets.

Four rules worth creating

Assign new tickets fairly — trigger
IF Event is Ticket created AND Team is not empty → Assign to the next agent (round-robin). Each new ticket lands on the least-loaded agent of its team.
Tag by keyword — trigger
IF Event is Ticket created AND Subject contains “invoice” → Add tags billing. Route and report on a topic without anyone reading the subject line.
Escalate stale tickets — scheduled
IF Status is Open AND Priority is not High AND Hours since update ≥ 24 → Set the priority to High. Loop-safe: once the ticket is High, “Priority is not High” no longer holds, so it never re-escalates.
Close solved tickets — scheduled
IF Status is Solved AND Hours since update ≥ 96 → Set the status to Closed. Loop-safe: a Closed ticket falls out of the sweep.

Read the shorthand as the list summary does: If … → …. In the builder each part is a real dropdown row.

IF   Status         is        Open
AND  Priority       is not    High
AND  Hours since update  ≥     24
→    Set the priority   High