ServiceNow Round Robin Assignment: Round Robin Ticket Assignment and Auto Assignment Options

Does ServiceNow have round robin assignment built in?

Not on the engine most people mean when they say assignment. A legacy assignment rule is a record on sysrule_assignment, and the ServiceNow SDK schema for it lists exactly what you get: name capped at 40 characters, table which must extend task, active, condition as an encoded query capped at 1000 characters, match_conditions set to ALL or ANY with ALL as the default, a group reference, a user reference, a script field capped at 8000 characters of server-side JavaScript, and an order integer that defaults to 100 where lower numbers run first. There is no strategy field, no rotation field, and no counter. The rule fires, the first match wins, evaluation stops, and the group named on that rule gets stamped. Run it a thousand times and you get the same group a thousand times. Rotation exists elsewhere in the platform, in Advanced Work Assignment, and it exists in whatever script you write yourself, but it is not a setting you switch on inside the rule you already have.

ServiceNow round robin ticket assignment through Advanced Work Assignment

AWA is the closest thing ServiceNow ships to a real routing engine, and its Last Assigned strategy is what most people are sold as round robin. It routes each work item to the eligible agent who has gone longest without being assigned work on that service channel. The second strategy, Most Capacity, routes to whoever has the most capacity remaining, tracked as ac_workload against a capacity value set per presence state. Both are configured on the work item queue, and the agents who can receive from that queue come from the Assignment Eligibility related list, where an Eligible at value of 0 marks the primary tier and higher values create overflow tiers.

The part worth planning for is everything that has to exist first. AWA needs the com.glide.awa plugin, and the plugin is not sold on its own: it requires an active ITSM, CSM, or HR Service Delivery subscription. It has to be used with a workspace containing the Agent Inbox, because that is where offers appear. Every agent needs a presence state, and the property com.glide.awa.agent_inactivity_threshold_seconds will quietly flip an idle agent to unavailable. Custom service channels are only possible for child tables of Task or Interaction. None of that is a reason to avoid AWA, but it is why a request for round robin sometimes comes back as a licensing conversation.

ServiceNow auto assignment round robin: pushing work instead of offering it

Classic AWA offers a work item and waits for the agent to accept it in the Agent Inbox. That is deliberate, and for chat it is the right model, but for an incident queue it adds a step and it means an item can sit unaccepted. Since the Utah release you can set Enable auto-assign work items on an AWA assignment rule, which pushes the item directly to the selected agent rather than offering it. That single setting removed the reason most of the older community scripts existed, and it is worth checking before anyone quotes you for custom development.

If you are on an older instance or outside AWA entirely, the community pattern that predates it does the same thing with a before Insert business rule on Incident, conditioned on Assigned to is empty. It queries group members, filters them against awa_agent_presence for an Available state, orders the survivors by a custom last-assigned field on sys_user, assigns the oldest, and stamps that user with the current time. The trade the author names openly is that agents no longer have to accept the request, so the ticket lands whether or not anyone is looking at the inbox.

Writing a round robin business rule yourself, and the two ways it breaks

The do-it-yourself route is genuinely common and it is not unreasonable. There are two patterns and they fail differently, which matters more than which one is prettier.

The timestamp pattern adds a datetime field to sys_user, then queries sys_user_grmember for the group and calls orderBy on that field, so the member who has waited longest comes first. After assigning, it writes the current time back to that user. It survives team changes cleanly, because there is no index to invalidate: a new joiner simply appears in the list. Its failure is the one reported repeatedly on the ServiceNow Community, where the complaint is that the solution is flooding a single technician with multiple tickets. That happens because an agent whose field is empty sorts ahead of everyone with a real timestamp, and stays there until the field is seeded, and because ordering by idle time is not the same as taking turns.

The counter pattern stores the last index in a system property and computes the next one with a modulo, in the shape nextIndex = (lastIndex + 1) % members.length. This is real circular rotation and it is the only option here that gives an exactly even split. Its weakness is membership: the stored index is a position in a list, so the moment somebody joins or leaves the group, the saved number points at a different person and the cycle restarts from an arbitrary place. If you rotate several groups you also need a property per group, and those properties are easy to lose in an update set.

One detail applies to both. ServiceNow processes before business rules with order below 1000, then the system engines including the assignment rule engine, then before rules at 1000 and above. If your rotation needs to override or follow the assignment engine, the order value decides whether it runs before or after it, and an order below 1000 is the usual reason a carefully written rotation gets stamped over.

Why round robin stops being fair, and what to measure instead

Round robin is a fairness mechanism that only works if the things being distributed are interchangeable. Tickets are not. An even count across six agents is a very uneven day if two of those agents drew the escalations, and idle-time strategies actively reward speed, because closing quickly returns you to the front of the list sooner. That is the structural reason teams reach for round robin, get an even count, and still hear that the workload is lopsided.

Before changing the strategy, get the numbers. The metric_instance table is the right place: a field value duration metric definition on the assignment group field records what the field changed to, how long it stayed there, and which task it belonged to, so you can see dwell time per group rather than a raw count. Two conditions catch people out. The field has to be audited or the metric never populates, and metrics do not backfill, so a definition created today tells you nothing about last quarter unless you generate the historical instances with a fix script. The reassignment_count field on the task is a cheap companion: it will not tell you who touched a ticket, but it filters straight to the ones that bounced.

Choosing between AWA, a script, and a routing layer beside ServiceNow

If you already own ITSM or CSM, you are running Agent Workspace, and idle-time rotation is close enough to fair for your queue, use AWA. It is supported, it is configured rather than coded, and turning on auto-assign removes the acceptance step. If your instance is small, one group needs rotation, and you have somebody who will still be here to maintain it, the counter business rule is fifty lines and will do exactly what it says.

The case for a routing layer beside ServiceNow is narrower and worth stating honestly. It is strongest when you need weighting, when the same people also take leads or ops work that ServiceNow cannot see, when you need availability and skills together without buying a tier to unlock them, or when you have been asked to explain, on the record, why a specific ticket went to a specific person. Assigner covers those, runs true circular rotation rather than idle-time ordering, and names the rule behind every assignment. It does not replace ServiceNow and it does not want the incident record: it decides who, and lets ServiceNow stay the system of record.

Does ServiceNow have round robin assignment?

Not on legacy assignment rules. A record on sysrule_assignment has a table, condition, group, user, script, and order, and none of them rotate, so a matching rule stamps the same group every time. Rotation comes from Advanced Work Assignment, which offers work to the agent idle longest, or from a business rule you script yourself, or from a store app.

How do I set up round robin ticket assignment in ServiceNow?

Pick one of three routes. Configure an AWA work item queue with the Last Assigned strategy and an assignment eligibility pool, which needs the com.glide.awa plugin and an ITSM, CSM, or HRSD subscription. Or write a business rule on the Task table that orders sys_user_grmember members by a last-assigned timestamp or a counter property. Or run a routing layer beside ServiceNow.

What is the difference between AWA Last Assigned and true round robin?

Last Assigned picks whoever has gone longest without being assigned work, which is idle-time ordering. True round robin cycles through a fixed list in order, so each agent takes one turn before anyone takes a second. They match only while handling times are identical. Once one agent closes faster, that agent resurfaces at the top of the list more often and the counts pull apart.

Why is my ServiceNow round robin flooding one technician?

Almost always an empty sort field. In the timestamp pattern, an agent whose last-assigned datetime is blank sorts ahead of every agent holding a real value, so that agent keeps winning the query until the field gets a value. Seed the field for every group member, and confirm the rule writes the timestamp back on every assignment rather than only on some branches.

Can a ServiceNow assignment rule do round robin with a script?

Yes, within limits. The script field holds up to 8000 characters of server-side JavaScript, it can read the record through the current variable, and the SDK notes that a script silently overrides the static group and user set on the same rule. So you can query group members and choose one. What you cannot do is store rotation state in the rule itself, so the pointer still has to live on sys_user or in a system property.

What order should a round robin business rule have in ServiceNow?

Above 1000 if it needs to run after the assignment rule engine. ServiceNow runs before business rules with order below 1000, then all system engine processing, then before rules at 1000 and above. A rotation ordered below 1000 runs before the assignment engine, which then stamps its own group over the top, and that mismatch is the usual reason a correct script appears to do nothing.

Does ServiceNow round robin respect agent availability or shifts?

Only if you build it in. AWA reads presence state, so an agent who is not in an available state is skipped, and the com.glide.awa.agent_inactivity_threshold_seconds property flips inactive agents to unavailable automatically. A hand-written rule sees nothing unless you filter the member list against awa_agent_presence yourself. Neither route reads a shift schedule, so on-call rotations need a separate schedule lookup.

Can ServiceNow do weighted round robin?

Not natively. AWA offers Last Assigned and Most Capacity, and neither accepts a weight, so every eligible agent takes an equal share by default. Most Capacity is the nearest approximation, because a lower capacity value on a part-time agent reduces how much concurrent work they hold, but that caps work in progress rather than dividing the incoming stream in a chosen ratio.

Why is my ServiceNow assignment rule not assigning anything?

The most common cause is that assignment group or assigned to is already populated, because assignment rules never overwrite an existing value. After that, check the target table actually extends Task, since rules only apply to task-extended tables. Then check match_conditions, which defaults to ALL, and the order value, since the lowest matching order wins and evaluation stops there.

Do I need Advanced Work Assignment to rotate tickets in ServiceNow?

No, but the alternatives are code or a third-party layer. AWA is the supported configuration route and since the Utah release its assignment rules can set Enable auto-assign work items to push work directly instead of waiting for acceptance. Without AWA you are writing and maintaining a business rule, or running a routing tool beside ServiceNow that does not need the plugin or the workspace.

How do I report on whether ServiceNow round robin is actually fair?

Report on metric_instance rather than ticket counts. A field value duration metric definition on the assignment group field records what the value changed to, how long it stayed, and which task it belonged to, so you get dwell time instead of a count. The field must be audited or nothing is written, and metrics do not backfill, so create the definition before the quarter you want to measure.