How Priority Flows Work¶
Priority Flows put every piece of work waiting for your agents on one scale. A flow gives an arriving item a starting score, runs an ordered list of rules over it β a VIP customer adds 300, a deadline inside 24 hours adds 220 β and hands it to a destination queue, where the score keeps growing while the item waits. An agent is then offered the highest-scoring item across every queue they serve, whatever channel it arrived on.
Priority Flows are optional. If you change nothing, nothing changes: agents carry on picking tickets out of views and sorting by SLA deadline. Nothing is pushed to anybody until you create a ticket queue or a ticket distribution rule.
When you are ready to build, follow Set Up Priority Flows β it takes you through all the steps in the right order.
Three Ways to Run Tickets¶
Each level builds on the one before it. Stop wherever suits the team β and different teams on the same instance can sit at different levels.
| Level | What it is | What you configure |
|---|---|---|
| 1 β Manual | What you have today. Nothing is pushed; agents pick tickets out of views and sort by SLA deadline. | Nothing. This is the state of an instance with no ticket queue and no distribution rule. |
| 2 β Ticket queue | Tickets are pushed to agents, with a base queue priority and the queue's own SLA ageing. No rules to write. | A ticket queue, and a ticket distribution rule that sends tickets into it. |
| 3 β Priority Flows | The scored rules engine on top, weighing every channel's work on one scale. | A flow with its conditions and targets, plus a source that feeds it. |
One Funnel, One Word for the Work¶
A single piece of work β one call, one chat, one message, one ticket β is an activity. Priority Flows are the funnel every activity can pass through on its way to an agent:
flowchart LR
A["Channel inbound routing"] --> F
B["Ticket distribution rule"] --> F
C["External system (API)"] --> F
F["Priority flow<br/>starting score + rules"] --> Q["Destination queue<br/>score grows while waiting"]
Q --> AG["Agent<br/>highest score first"]The flow scores the work. The destination queue β a ticket queue or one of your existing channel queues β receives it and ages it. The distribution matrix decides how much one agent holds at once, and the queue's distribution strategy decides which agent is tried.
How Scoring Works¶
An activity enters the flow at the flow's Default priority score, then every rule whose conditions match adds its own increment on top. Rules are checked in order from 1 upwards, and every match adds β the score is built up rather than picked from a list.
| Step | Score |
|---|---|
| Enters the flow at the flow's default priority | 100 |
| Rule 1 β contact is in the VIP database | +300 |
| Rule 2 β first answer overdue Β· no match | β |
| Rule 3 β SLA deadline inside 24 hours | +220 |
| Score when it reaches the queue | 620 |
The numbers here are examples, not defaults. What a live call is worth next to a two-day-old ticket is yours to set.
A rule can also do two other things when it matches. An Exception rule sends the activity to a specific destination queue instead of the flow's usual target β the first matching exception wins, later ones are ignored, and evaluation carries on. Stop is the only way to end evaluation early; everything already accumulated stays in place.
Two flow-level settings frame the result: Maximum priority score caps the total the activity leaves the flow with (leave it empty for no cap), and a rule with a negative increment can lower the running total but never take it below 0.
Priority Is Compared Globally¶
Priority is compared across queues, not inside one. An agent is offered the highest-scoring activity across every queue they serve, within the limits of the distribution matrix, their Rank on that queue and the queue's own strategy for choosing an agent. Rank decides which agents are tried first β it never breaks ties between activities and never weights a score. Among the activities an agent is eligible for, the order is by score alone.
A ticket sent straight to the same queue, without a flow, would start from that queue's own Priority β say 250 β and climb as it waits. Whichever number is higher at the moment an agent becomes free is the one that gets answered.
Info
Priority and score are the same number. Priority is what you set; score is what an activity is carrying once the rules and the waiting have done their work. A queue's Priority field is a free number in the same space as flow scores, not a 0β10 level.
How a Flow Is Fed¶
A flow does nothing until something sends activities into it. There are three sources, and a flow's Entry points tab lists everything currently pointed at it.
| Source | What it covers | Where you set it |
|---|---|---|
| Channel inbound routing | Calls, SMS, web chats, Facebook, WhatsApp, Viber, Instagram β point the routing's next destination at the flow. | The channel's own routing, e.g. Call Routings. |
| Ticket distribution rule | Tickets, including every ticket created from an email β an email becomes a ticket first, its email routing runs exactly as it does today, and the rules decide afterwards. | Ticket Distribution Rules. |
| External system | Anything outside Daktela can put a ticket into a flow over the API: PUT /api/v6/tickets/<name>.json with { "dist": true, "priority_flow": "<flow_name>" }. |
Your own integration. |
Email is never a channel-routing source β it always arrives as a ticket, through a distribution rule.
Campaign records as a flow target arrive in a minor update shortly after 2026.2.
An activity starts at the flow's Default priority score, or at whatever entry priority the distribution rule that sent it chose, or from the queue's own Priority if no flow was involved.
Where Ageing Lives¶
Scores keep growing while an activity waits, so nothing sinks quietly to the bottom. Ageing is set on the queue, not on the flow, so it applies whether or not a flow was involved β a ticket enqueued directly ages exactly like one that arrived through a flow.
- On a ticket queue, growth is staged against the ticket's SLA deadline: a baseline rate while within SLA, one or more steps as the deadline nears, and a separate rate once it has passed.
- Every other queue type gets a single flat increment per period instead.
Warning
Two queues ageing at different rates will let their activities overtake one another over time β a fast-ageing queue's ticket climbs past an older ticket sitting in a slower one. Worth knowing before you set the rates.
Two Sets of Rules, on Purpose¶
Distribution rules and flow rules look similar and behave deliberately differently. They run in sequence: the distribution rule decides whether a ticket enters distribution at all and the score it arrives with, and the flow builds on that.
| Ticket distribution rules | Priority flow rules (Conditions) | |
|---|---|---|
| Question they answer | Does this ticket enter distribution, and where does it go? | How important is this activity? |
| How matches combine | First match wins. Rules are evaluated in ascending Order and no rule below the match is evaluated. | Every match adds. Evaluation continues through the whole list unless a matched rule has Stop turned on. |
| What a match produces | One destination: a flow (at an entry priority) or a ticket queue. | A score increment, and optionally an exception destination queue. |
What Does Not Change¶
- Email queues. Mailbox and email routing configuration stay exactly as they are today. The rules layer sits on top: email routing applies first, rules decide afterwards. See Email Queue.
- Manual ticket handling. A ticket that matches no rule is handled by hand, exactly as now β it stays in the ticket views and agents sort by SLA deadline.
- Nothing is pushed until a ticket queue or a distribution rule exists.
- Deadline calculation. SLA deadlines are still derived from the category or the account's SLA; ticket-queue ageing only reads them.
- The category's own Distribution setting is a separate, older mechanism β see Categories. The two can coexist.
Every Decision Is on the Record¶
Every activity that passes through distribution keeps a process log: the flow it entered and its starting score, every matched condition and what it added, each SLA ageing step, the exception queue if one was latched, interruptions, any manual override with who made it and where, and a distribution timed out event if the queue's maximum wait ran out.
In Realtime, waiting activities show their live score in the Priority column, an SLA stage column (Within SLA, Nearing with the active step and rate, or After deadline) and an Interruptions column. A team leader with the Realtime monitoring permission can type a new value into the Priority cell to override an activity's score by hand; the override is badged as manual, SLA ageing keeps adding on top of it, and the change is written to the process log.
Priority Flows reporting summarises handled activity, average wait in the pool, SLA on target, interruptions and the average score at assignment, with a per-channel completed-versus-interrupted breakdown and a table of processed interactions whose rows open the process log.
Before You Start¶
- Administrator access to the Settings section of Daktela.
- A working helpdesk if you are distributing tickets β categories, SLA and working hours in place. See How the Helpdesk Works.
- The queues your work should land in, or a plan for them β a ticket queue for tickets, your existing channel queues for calls, chats and messages.
- Agents assigned to those queues, with their Rank set on their profile.
- An agreed scale. Decide what a live call is worth next to an overdue ticket before you start typing numbers into rules.
Ready? Continue to Set Up Priority Flows.
Reference Pages¶
- Set Up Priority Flows β the end-to-end guide.
- Priority Flows β every field on the flow form.
- Ticket Queue β the queue type tickets are pushed from.
- Ticket Distribution Rules β which tickets enter distribution, and where they go.
- Queue Basics β agents, relations and the distribution matrix shared by all queue types.