Assignment methods and assignment rulesets

What it does

The last stage of unified routing. Once a work item is sitting in a queue, the queue's assignment method picks who gets it — either one of the out-of-the-box strategies, or a custom pair of rulesets that you write yourself to order the work and then order the people.

Key facts

Assignment method is set per queue, not per workstream, so different queues in the same workstream can behave differently.
Out of the box: Highest capacity, Advanced round robin, Least active, and no auto-assignment (pick-based). Highest capacity breaks ties with round robin; advanced round robin seeds order by when users joined the queue and then tracks assignment history queue by queue. Least active measures time since capacity was last released and is voice and messaging only.
Custom assignment uses two ruleset types: a prioritisation ruleset that orders the work items, and an assignment ruleset that selects and sorts the people.
A queue can have at most one prioritisation ruleset. Each rule in it creates a priority bucket; items matching no rule fall into the last bucket, ordered FIFO.
Assignment rules carry Order, Name, Conditions and Order by. Conditions can test system user attributes, presence, capacity, skills, calendar schedule and bot attributes. Order by options include least active, round robin, unit or profile-based capacity, proficiency and skill count.
Custom methods do not inherit the workstream's presence, capacity or skill-matching settings. You have to express all of it in the rules, which is the single most common cause of custom assignment behaving oddly.
Operating hours are ignored by the out-of-the-box methods. To respect a shift pattern you need a custom rule using the is working operator against a calendar schedule.
The assignment cycle fires on a new work item, a presence change, a runtime capacity change, a user being added to a queue, and on a periodic sweep roughly every five minutes for record-type work items.
Declines: the default limit is 3 per work item, configurable 1 to 5 via msdyn_number_of_declines_allowed on msdyn_omnichannelconfigurations. Past the limit that person is dropped from auto-assignment for that item but can still pick it manually. Once around 100 people have declined, the item leaves the auto-assignment cycle entirely.
Dynamic prioritisation (natural-language driven, priority score 0 to 100,000, minimum 30-second wait interval) is a preview capability aimed at conversations and is incompatible with custom prioritisation rules. Confirm its wave status before quoting it.
Cross-queue ordering uses the queue Queue priority field; equal priorities fall to FIFO, or to alphabetical queue order when custom rules are in play.
Scale limits were published on 11 September 2026 and they are not the same for both routes. Default methods support a 50,000-item backlog, 5,000 incoming conversations a minute, 5,000 users per queue and 100 queues when cross-queue prioritisation is on. Custom assignment supports 10,000 items, 500 conversations a minute, 2,000 users per queue and 20 queues. See Assignment scale limits.

When to use / skip

Start with an out-of-the-box method. Highest capacity is the sensible default for record work: it spreads cases toward whoever has room, and the round-robin tie-break stops the same person being hammered. Advanced round robin is the one to reach for when the client's fairness argument is about counts rather than workload.

Go custom when there's a rule the standard methods genuinely cannot express — respect shift schedules, prefer a named team before falling back to a wider pool, sort by proficiency, or prioritise by something other than arrival order. Those are real requirements and custom rulesets handle them well.

Don't go custom because it feels more capable. Custom assignment means you own presence filtering, capacity filtering and skill matching by hand, and a rule that quietly omits a presence condition will assign work to people who are offline. Most implementations should be out-of-the-box on most queues, with one or two custom queues where the business case is clear.

Configuration decisions

Method per queue, and whether every queue really needs the same one. Uniformity is easier to support; variation is sometimes the point.
Push or pick. Pick-based queues put control with the agent and give you far less to configure, at the cost of cherry-picking.
If custom: whether a prioritisation ruleset is needed at all, or whether FIFO within the queue is fine and only the person-selection needs rules.
The decline limit, between 1 and 5, and what the client expects to happen to an item everyone has declined.
Whether operating hours must be honoured — this alone forces a custom assignment ruleset.
The Order by strategy inside each assignment rule, which is where fairness versus competence actually gets decided.

Gotchas

Custom assignment has a fifth of the throughput ceiling of the out-of-the-box methods and a fifth of the queue count once cross-queue prioritisation is involved. Sizing is done at design time and the limits weren't documented until September 2026, so plenty of existing custom builds are sitting closer to the edge than anyone realises.
Custom rules that omit a presence condition will offer work to people who are away. The workstream's allowed presences do not apply to custom methods and nothing warns you.
Advanced round robin order is held per queue. Moving someone between queues resets their position, so "fair rotation" quietly restarts every time the team is reorganised.
Least active only applies to voice and messaging. Selecting it in a records context does not do what the name suggests.
The five-minute sweep means record assignment is not instantaneous. Clients who have seen a chat demo expect sub-second and will log the delay as a defect unless you set expectations early.
Prioritisation buckets are coarse. Everything in bucket one is FIFO among itself, so a rule that matches most items gives you almost no prioritisation at all.
Affinity work items are assigned ahead of other queue items, which can look like the prioritisation ruleset being ignored.
Changing the decline limit is an OData operation against the Omnichannel configuration, not a UI setting. It's easy to forget at go-live and easy to lose at handover if undocumented.

Consultant notes

Show the client highest capacity and advanced round robin side by side with five test users. The difference is obvious in a demo and impossible to convey in a document.
Take the client's peak-hour conversation rate and agent-per-queue counts before you agree to custom rulesets. The published limits turn what used to be a maintainability argument into a hard one: above 500 conversations a minute or 2,000 users on a queue, custom assignment isn't an option regardless of how elegant the rules are.
Push back on "assign to the best person" as a requirement until someone defines best. Usually they mean most proficient, and they haven't thought about what happens when that person is on leave.
If you build custom rulesets, write the presence, capacity and skill conditions first and the clever part second. That ordering habit prevents the most damaging class of bug here.
Record the decline limit and its current value in the handover pack, alongside how to change it.
Before go-live, test the everybody-declines path. Someone will decline out of habit and the client needs to know where that case ends up.

Worth another look when dynamic prioritisation reaches general availability, if the published scale limits move, or if the client introduces shift-based working.