Ticket Distribution Rules¶
Distribution rules are the one place that decides whether a ticket enters distribution at all, where it goes, and at what priority. Until a rule exists, no ticket is pushed to anybody β agents keep picking tickets out of views. For the wider picture see How Priority Flows Work; to build the whole chain, follow Set Up Priority Flows.
Go to Settings β Tickets β Distribution Rules. Each rule opens as its own detail page.
Which Destination to Choose¶
Every distributed ticket passes through a rule; what differs is where the rule sends it.
| Destination | Use it when |
|---|---|
| Ticket queue | The queue's own Priority and SLA ageing are enough. The ticket is enqueued directly, starts from the queue's Priority, and is ordered by priority and then wait time. No rules to write. |
| Priority Flows | Importance depends on the ticket β the customer, the deadline, the category. The ticket enters the flow's funnel, where every matching rule adds to its score, and is then compared against work from every other channel on the same scale. |
Rule Fields¶
| Field | Description | Default / options |
|---|---|---|
| Title | The name of this rule as it appears in the Distribution rules list. Use something that describes what triggers it, not a generic label. | Required |
| Description | Optional note for other admins explaining why this rule exists. It has no effect on how the rule is evaluated. | Optional |
| Active | Turns this rule on or off. While inactive, the background service skips it completely. Tickets it already routed before are not affected. | Toggle |
| Order | This rule's position among all distribution rules. Rules are evaluated starting from the lowest number, and the first one whose conditions match sends the ticket; rules further down are not evaluated for that ticket. | Required |
| Conditions β AND group | Every condition in this group has to be true at the same time for the rule to match. Use it for conditions that always must hold, such as an event type or a status. | β |
| Conditions β OR group | An optional second group. When it has any rows, at least one of them must also be true on top of everything required above. Leave it empty if the rule only needs the group above. | Optional |
| Next destination | Where the ticket goes once this rule matches. Priority Flows enters the chosen flow's funnel at the Entry priority set below. Ticket queue enqueues the ticket directly and uses that queue's own Priority instead. | Priority Flows (flow picker) or Ticket queue (queue picker) |
| Entry priority | The score the ticket enters the flow with. | Flow default (pre-selected) or Explicit value. Not applicable when the destination is a ticket queue β that uses the queue's own Priority. |
No dropdown starts blank: every one pre-selects a real value, and every time-unit selector starts at Minutes.
The rules list shows each rule's Active toggle, Order, Next destination β the resolved target, naming the specific flow or queue β and Description.
Building the Conditions¶
There is no separate trigger setting: a rule fires when its conditions are met. The field dropdown groups the ticket's own data and keeps the checks that stand on their own ungrouped.
| Group | What it offers |
|---|---|
| Entry occurrence | What just happened: New ticket, New incoming e-mail or New comment. |
| System field | Every ticket column, plus the related CRM contact and account fields. |
| Custom field | Any custom field on the ticket. |
The following checks are not grouped β they appear on their own in the dropdown:
| Condition | What it matches |
|---|---|
| Deadline | How close a deadline is: Deadline or First answer, plus a number and a time unit. Operator: deadline within. |
| Time in field value | How long the ticket has sat in the current value of any system or custom field, plus a number and a time unit. Operator: set at least. |
| Stage / Status transition | A move from one Stage or Statuses value to another. Either side may be left blank, meaning "from anything" or "to anything". Operator: changes. |
| Created from email queue | The email queue the ticket was created from β enough on its own to distribute everything arriving in one mailbox. |
| Matched email routing rule | An existing email routing rule that applied to the ticket. Optional. |
Operators are eq, is not, is one of, is none of, is empty, is not empty, and the three above. Time units are Minutes (default), Hours and Days.
Note
Stage / Status transition matches an actual change from one value to another, not a save that leaves the value unchanged.
Tip
Time in field value works on any system or custom date field, so you can escalate on how long it has been since your own field was last set, not just on a fixed list of statuses.
How Rules Are Evaluated¶
- First match wins. Rules are evaluated in ascending Order, and once one matches, the ticket is sent to that rule's destination β no rule below it is evaluated for that ticket.
- A background service re-checks the rules every 30 seconds, so a ticket on an approaching deadline escalates on time without anyone opening it.
Which Tickets Are in Scope¶
Before any rule's conditions are checked, the ticket has to be eligible:
- It is not a merged ticket.
- It is not already sitting in a ticket queue.
- It has not already been sent into distribution.
There is deliberately no gate on stage or on the assigned user β a ticket that is already open, or already has an owner, can still be picked up by a rule, because escalating one is exactly what a rule is for. A ticket leaves scope for one reason only: it is already in a ticket queue.
A ticket that matches no rule is handled by hand, exactly as before: it stays in the ticket views and agents sort by SLA deadline.
What the Agent Sees¶
Accepting a distributed ticket sets its Stage to Open and assigns it to the accepting agent in a single silent update: no notifications are sent and no event automations are triggered. The agent's own view reflects the change immediately, without a refresh. See Tickets β Automatic State and User Changes.
Email Tickets¶
Email has no separate entry into distribution. An incoming email becomes a ticket first, its email queue and email routings run exactly as they do today β setting the category, statuses, custom fields and assignments β and the distribution rules are evaluated afterwards. Mailbox and routing configuration are unchanged.
Because routings run first, everything they already sort out is available to a distribution rule as a condition. Match on Matched email routing rule or Created from email queue, and the routing's own criteria β the VIP domain, the complaint subject, the mailbox that belongs to one team β decide whether the ticket is distributed; the rule itself only says where it goes and at what priority. You do not have to restate sender, subject or address conditions that already exist on the routing, and when you change that routing later, every distribution rule pointing at it follows along.