… 12 unchanged lines …
  - 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](https://learn.microsoft.com/en-us/dynamics365/customer-service/implement/service-quotas#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.
    … 11 unchanged lines …
  - 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.
    … 4 unchanged lines …
  
  ## 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.
    … 1 unchanged line …
  
  ---
  
- *Worth another look when dynamic prioritisation reaches general availability, or if the client introduces shift-based working.*
+ *Worth another look when dynamic prioritisation reaches general availability, if the published scale limits move, or if the client introduces shift-based working.*