Release Notes 2026.2

Until now every queue distributed its own channel, and nothing could answer a simple question: what is the most important thing in the contact centre right now? A VIP email could not outrank a waiting call. A deadline three hours away could not escalate anything. Backlog work could not be blended with live traffic. Daktela 2026.2 answers that question, and most of the rest of this release exists to support the answer.

Priority Flows is Daktela's unified queue — the capability also sold as omnichannel routing or a universal queue. One funnel every channel enters, one number that decides what comes next, and a record of how every decision was made.

None of it is forced on anyone. Pushing work to people is something you switch on, and if you change nothing, nothing changes. What the upgrade does on its own — and what it leaves alone — is set out at the end.

How far you go is your choice

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 1

Manual

What you have today. Nothing is pushed, and nothing starts being pushed until you build a ticket queue or a rule.

Level 2

Ticket queue

Push distribution, a base queue priority, and the queue's own SLA ageing. No rules to write.

Level 3

Priority Flows

The scored rules engine on top, weighing every channel's work on one scale, with reporting and a full audit trail.

Unified distribution

How the one queue works

Priority Flows scores the work. Ticket queues and your existing channel queues receive it. Ticket distribution rules decide which tickets enter at all. The distribution matrix decides how much one agent holds at once. Channel rotation decides what kind of work they get next. A single piece of work — one call, one chat, one message, one ticket — is an activity.

New feature

Priority Flows

A flow gives every arriving item a starting score, then runs an ordered list of rules over it — a VIP customer adds 300, a deadline inside 24 hours adds 220. Every rule that matches adds to the running total, so priority is built up rather than picked from a list.

Priority is compared globally: an agent is offered the highest-scoring item across every queue they serve, whatever channel it arrived on, within the limits of the distribution matrix, their rank on that queue, and the queue's own strategy for choosing an agent.

The numbers here are examples, not defaults. What a live call is worth next to a two-day-old ticket is yours to set.

One ticket through a flow

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

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.

How a flow is fed

Calls, chats and messages reach a flow from the channel's own inbound routing, where you point the next destination at the flow. Tickets reach it through a ticket distribution rule — that includes every ticket created from an email, because an email becomes a ticket first and its email routing runs exactly as it does today. Anything outside Daktela can put a ticket into a flow over the API.

An item starts at the flow's default priority, or at whatever entry priority the rule that sent it chose, or from the queue's own priority if no flow was involved, and the queue's ageing takes over once it is waiting. The setup steps are in the documentation.

Priority and score are the same number. Priority is what you set; score is what an item is carrying once the rules and the waiting have done their work.

New feature

Ticket queues

A new queue type that pushes tickets to agents instead of waiting for someone to pick them out of a view. If you already run a call or chat queue you know how to run this one — it keeps the same settings: how it picks an agent, how agents sign in, working hours, wrap-up, trying the last agent or the ticket owner first, and where work goes if it waits too long.

A ticket queue also works as a flow's destination: a ticket arriving from a flow keeps its score and interleaves with directly enqueued tickets by plain number comparison.

New feature

How a waiting item's score grows

Scores keep growing while an item waits, so nothing sinks quietly to the bottom. On a ticket queue that growth is staged against the ticket's SLA deadline: a baseline while it is within SLA, one or more steps as the deadline nears — five days out it might add 500 a day, one day out 800 every twelve hours — and a separate rate once the deadline has passed. Every other queue type gets a single flat increment per period instead.

Ageing is set on the queue rather than on the flow, so it applies whether or not a flow was involved. Two queues ageing at different rates will let their items overtake one another over time — worth knowing before you set the rates.

New feature

Ticket distribution rules

One place to decide whether a ticket enters distribution, where it goes, and at what priority. A rule filters on ticket events, elapsed time, and ticket or CRM fields — a new incoming email, a deadline within the hour, a ticket untouched since a chosen date field was last set, a status change that actually moved. Conditions sit in two groups: everything in the first must be true, and at least one thing in the second.

A background service re-checks the rules every 30 seconds, so a ticket on an approaching deadline escalates on time without anyone opening it.

Two sets of rules, on purpose

For a distribution rule, the first one that matches decides, and settles whether the ticket enters distribution at all. Inside a flow, every rule that matches adds to the score, and a rule can also fix where the item ends up. They run in sequence: the rule sets the score a ticket arrives with, the flow builds on it.

Email never arrives as a channel connector: an email becomes a ticket first, its email queue's routing runs as it does today, and the ticket rules decide afterwards. Campaign records follow in a minor update.

Rework

The distribution matrix, in plain numbers

How much work one agent holds at once, and which channels block which, is now one card per incoming channel — "when a call comes in…" — reading in whole agents rather than as a grid. A card says Max 3 at once, and block a new call once the agent already has two or more open web chats, with per-card presets for the two common cases: blocked by any other open work, or never blocked.

This changes what you see, not what happens. Your existing settings carry over untouched, the effect on every agent is identical, and there is nothing to reconfigure.

The contact centre now has one global matrix that always exists — the floor every agent falls back to — and a profile either inherits it or explicitly overrides it on its own Distribution matrix tab. Edits are staged and flagged until you save, and editing the global default needs the Global settings permission; without it the same screen opens read-only.

New feature

Agent channel rotation

"After two calls in a row, make this agent less likely to get a third." Rotation shapes the sequence of an agent's work; the distribution matrix governs how much they handle at once. Rules sit on the profile's Channel rotation tab: after a set number of consecutive interactions of one kind — a single channel, or a whole category such as any chat — the agent's rank for that kind drops by an amount you choose on a 1–10 scale, so other work becomes more likely to reach them next.

It is a bias, never a block: a deprioritised agent still takes the item when nobody better is free, and work at risk of breaching SLA always wins. Rotation is off until a profile switches it on; there is no contact-centre-wide default.

Coming soon

Campaign records join the queue

A call script will pair with a Priority Flow instead of a single campaign queue. Records enter the funnel as they become due, get scored on database, record attributes and how overdue they are, and the flow picks the outbound queue. The queue's campaign type still owns how it dials; the flow owns which queue, when, and who.

Sequential database mixing becomes an ordinary rule: condition on the record's database, give it a higher score, and the funnel serves that database while any of its records wait.

Campaign records arrive in a minor update to 2026.2, shortly after the main release.

Governance

Every decision is on the record

A routing engine that cannot explain itself is one you cannot defend to a customer, an auditor or your own team. Priority Flows reporting needs a flow; the decision record and the live score in Realtime apply wherever distribution is switched on.

The full decision record

Each interaction carries a process log — the record of everything that happened to it: the flow it entered and its starting score, each rule that matched and what it added, SLA increases, the exception that fixed its destination, manual overrides with who made them, and timeouts.

Watch the ranking live

Realtime gains the current score, the SLA stage — within SLA, nearing it with the step and rate currently in force, or past deadline — and interruptions, meaning live work the matrix allowed onto an agent who was already busy.

Override a priority by hand

Type a new score straight into the Realtime priority cell. The item is marked as manually set, ageing continues on top, and the override is written to the record with the person who made it.

Priority Flows reporting

How much work went through flows, how long it waited, how much of it hit its SLA, and what an item's score was when it reached an agent — with a per-channel breakdown, how much of the work an interruption displaced was picked back up, and a table that drills into any single interaction.

Why an agent was passed over

When channel rotation biases work away from someone, the reason is recorded — for example, two calls in a row.

Looking ahead

Why this matters beyond routing

Routing work intelligently needs two things the product did not have: one scale on which every piece of work can be compared, and a complete record of why each decision was made. 2026.2 builds both. There are no AI routing features in this release — but this is the layer they would need, and it is now in place.

Administration

One profile instead of Rights and Accesses

Permissions used to live in two objects that had to be maintained separately and linked per user. They are now a single Profile — what someone can do, what they can administer, which queues, categories and databases that applies to, and how they behave in the contact centre, across nineteen areas.

Rework

Profiles

A profile opens on four tabs: Access & scope, Distribution matrix, Channel rotation, and Members & overrides. Each area shows what a user can do, what they can administer, and which specific queues, categories, databases or macros that applies to — with a live indicator on every area that has anything switched on.

Several things moved to where people look for them: custom translations now sit under Workflows, the old GDPR right is now Anonymization under a new Data & privacy area, and new areas cover Activity handling, Workspace, AI functions, Devices and User management.

New feature

Lend agents a second profile

Every user has one primary profile, and can have further profiles attached on top of it. Attaching one only ever adds access — it can never take anything away from the primary — so putting some of your VIP agents on the regular queues for a busy afternoon no longer means building a throwaway rights group and unpicking it afterwards.

Attach from the user's own detail, from the profile's Members tab, or straight from Realtime › Users while you watch the queues — one agent or a whole selection at once. The profile’s Members tab shows every user it is attached to, and a user’s own detail shows every profile attached to them, with who attached it.

Time-boxing an attachment — planning when it starts and ends, and having it revert on its own — follows in a minor update to 2026.2. In the initial release, an attached profile stays until someone removes it.

New feature

Max tickets

A per-agent cap on open tickets, alongside the existing limits on activities and outgoing campaign records. It is enforced at the moment a ticket would be assigned, so ticket queues never push an agent past their limit.

Improved

Set every queue's login mode at once

The profile screen where you grant queues gains a bulk control for how agents sign in to them, applying across the whole queue list rather than just the page on screen, and touching only the queues the profile can see. Because an agent can hold just one active outgoing login, a bulk change that would leave two outgoing queues logged in stops and asks which one keeps it.

Agent workspace

Call and chat activities, redesigned

Activities were carried over one-to-one when Daktela moved to Neo, and they no longer matched the ticket redesign that shipped in 2026.1. Inbound, outbound, campaign and chat activities are rebuilt to sit properly next to the new ticket detail — the same capabilities laid out again, bar the two widgets noted below.

What your agents will see, and how to brief them

This is the one change every agent meets at their first login, so it is worth a few minutes at a team huddle.

The call or chat panel itself keeps its place — the Call panel on the right, the Web Chat conversation on the left — and everything that used to sit around it in a custom arrangement is now a tab beside it: Contact & Account, Activities, Assign ticket, and so on. One tab opens first, and an administrator chooses which. Two widgets are retired: Ticket – read only, which did the same job as Assign ticket, and Calendar, which is reachable from the activity screen itself. If a queue of yours used either, tell that team where to look instead.

New feature

Keep working without losing a conversation

Move away from a live call and a floating widget follows you around the app: the timer, direction and queue, who you are talking to, the same call controls, and Hang up.

Messages work the other way round. When one arrives on a conversation you are not looking at, a floating panel lists it — the unread count, how long it has been waiting, a preview of what they said, and a button straight back into the chat. It covers every message channel, not just web chat, and can be switched off per queue.

Rework

Widget settings, edited in the activity itself

The per-queue builder is no longer an abstract canvas of blocks and widths. It renders as the real activity screen and is edited in place: drag the tab bar to reorder it, star the tab that opens first, remove a tab or add an unused widget, and open any widget's own settings from its gear. Tabs preview with real content from the queue's most recent answered activity.

On campaign queues the record form is pre-placed and cannot be removed.

New feature

Contact and account on one tab

The separate Contact and Account widgets merge. With nobody linked the tab reads "Assign contact" and shows a searchable grid; with a contact linked it shows the contact's details and, beneath them, their account. Administrators choose which custom fields appear, per-entity.

New contacts and accounts can be created without leaving the call — add a contact from the grid header, or create an account straight from the contact's account field. Unsaved edits turn Close into Save & Close, so nothing is discarded silently.

Improved

The same widgets on every chat channel

Chat channels that were missing widgets calls already had — realtime users, knowledge base — now offer the full set. The palette is identical for calls and chats, with the record form the single call-only exception.

What stays the same

Nothing here happens to you by accident

If you change nothing, nothing changes.

Agents carry on picking tickets out of ticket views and sorting by SLA deadline. Tickets are pushed to people only once you create a ticket queue or a distribution rule — not before.

Email queues are unchanged.

Mailbox and email routing configuration stay exactly as they are today. The new rules layer sits on top: email routing applies first, rules decide afterwards, and a ticket that matches no rule is handled by hand, exactly as now.

What changes for everyone

What happens on its own when you upgrade

Everything else is something you choose. This is the whole list of what arrives on its own.

Rights and Accesses become Profiles

Each user's Rights object becomes their primary profile; their Accesses object becomes a profile attached on top of it. Effective access after the upgrade matches what it was before — same people, same permissions, one object to maintain instead of two linked ones.

An agent's priority on a queue is now their Rank

The number that decides which agents are tried first — set per queue on their profile — is renamed Rank, so it is no longer confused with the priority carried by the work itself. It now runs 0–10 with 10 as the highest, and existing values are converted during the migration. The number you read changes; the order agents are offered work in does not.

Dashboard layout and keyboard shortcuts move

They now come from the first profile attached to a user — which is exactly what their old Accesses object turns into.

Call and chat activities are laid out again

Every agent who takes calls or chats meets the new layout at their first login. The capabilities are the same, with two widgets retired because something else already does their job. What they will notice is described above.

The distribution matrix looks different

One card per incoming channel instead of a grid, reading in whole agents: "Max 3 at once" means three. Nothing about how much work reaches an agent changes.

Queue priority becomes a free number

On every queue type, in the same number space as flow scores, instead of the 0–10 levels you set before. It applies to work arriving at a queue directly; work arriving from a flow keeps the score it earned.

More improvements

And much more

Further changes across distribution, tickets and administration.

Distribution & queues

A waiting ticket is never lost

Set a maximum waiting time and what happens after it: overflow to another ticket queue, enter a flow with an optional escalation increase, update the ticket and release it to manual handling, or simply end the distribution activity while the ticket itself stays put.

Precise field updates on timeout

Each field on a timeout update chooses its own mode — set a value, replace what a multi-value field already holds, or clear it. Mandatory fields cannot be cleared.

Overflow lives on the queue

Where work goes if it waits too long is set on the queue itself, rather than repeated in every flow that points at it.

Flows cannot be saved half-configured

Every kind of work routed into a flow must have somewhere to go, and nothing can start sending a new kind of work to it until the gap is closed.

Export and import flows

Move a configured flow between environments rather than rebuilding it by hand.

Tickets

Accepting a ticket is silent

Taking a distributed ticket sets it to Open and assigns it to you in one update that sends no notifications and triggers none of your event automations — and your own view shows it immediately, without a refresh.

Wider distribution eligibility

A ticket that is already open, or already has an owner, can still be picked up by a rule. A ticket leaves scope for one reason only: it is already sitting in a ticket queue.

A tidier rule builder

Building a distribution rule's conditions means picking from a long list of ticket fields. That list is now grouped into what just happened, the ticket's own fields, and your custom fields — and nothing opens blank: every dropdown starts on a real value, and time units start at minutes.

Time in any field value

Escalate on how long it has been since any system or custom date field on the ticket was set — not just a fixed list of statuses.

Real status transitions

A transition condition matches an actual move from one stage or status to another, and no longer fires on updates where the value simply stayed the same.

Administration & security

Planned profile lending Coming soon

An attached profile will be able to carry its own start and end date, always ending at midnight so nobody loses access mid-shift. Plan one ahead and it shows as scheduled until it activates. Arriving in a minor update to 2026.2.

Clean exit when a profile is removed Coming soon

When an attached profile goes, the user loses only the queues it alone granted: their open activities in those queues are closed and they are logged out of just those queues. Queues granted elsewhere are untouched. Ships alongside planned lending.

Team leaders without full admin

A profile can be scoped to which users it may manage — by team or individually — and which other profiles it may edit.

Most favourable wins

Where a primary and an attached profile overlap, the more permissive setting applies: the higher rank, the wider action set, and whichever sign-in mode keeps the agent available in more queues. Two settings that cannot be merged — the single outgoing login and the distribution matrix — follow the primary profile.

Report a bug needs Resources

Resources, Report a bug and Request a feature sit together under what a user can do, and the latter two cannot be granted without the first.