ServiceNow Assignment Rules Not Working: Causes, Fixes, and Round Robin

ServiceNow assignment rules usually fail for one of five reasons: the record already has a value in assigned_to or assignment_group, the table does not extend task, a before business rule ordered below 1000 set the owner before the assignment engine ran, the conditions did not match because match_conditions is set to ALL, or the record came in through a channel that bypasses the engine. Assignment rules cannot overwrite an existing assignment, and that single fact explains most "not working" tickets. Below is each cause, how to confirm it in your instance, and what to change.

Why are my ServiceNow assignment rules not working?

In most cases the rule did not fire at all rather than firing wrongly. The assignment engine is narrow by design: it runs on task-derived records, it only fills in an assignment that is currently empty, and it sits at a specific point in the save sequence where earlier automation can quietly beat it to the field. Start by opening a record that should have matched and checking whether assignment_group or assigned_to already held a value at insert. That one check resolves a surprising share of cases.

The record already had an assignment group or assigned to value

This is the most common cause and the least obvious. ServiceNow assignment rules will not overwrite an existing assignment. If either assigned_to or assignment_group is already populated when the engine runs, the rule is skipped entirely. The value does not have to come from a person: a dictionary default on the field, a template, a record producer that maps a group, or a previously evaluated assignment rule will all populate it and lock the record out of every later rule. Clear the default, or move the logic you actually want into a single authoritative place, and the rule starts firing again.

The table does not extend task

Assignment rules only apply to tables that inherit from task: incident, change_request, problem, sc_req_item, change_task, sc_task, and custom tables built on task. On a non-task table the rule can exist, look correct, and never run, because the engine is never invoked for that table at all. This catches teams who build a custom application on a plain table and expect assignment rules to work the way they do on incidents. On a non-task table you need a business rule or a flow instead.

A before business rule set the owner first

ServiceNow runs before business rules with an order below 1000, then the engines, which is where the assignment rule engine lives. If one of your before business rules sets assigned_to or assignment_group directly, the record arrives at the engine already assigned, and per the rule above it is skipped. The fix is ordering. A business rule that should run after assignment needs its order set above 1000. A business rule that should feed the assignment rule needs to set the fields the conditions test, not the assignment fields themselves. When a rule and a script both want to own assignment, pick one and delete the other, because interleaving them produces results that look random to everyone reading the ticket later.

The conditions never matched the record

Assignment rules use an encoded query in the condition field, and match_conditions defaults to ALL, meaning every condition has to be true at once. Stack four conditions and it takes only one mismatch to skip the rule. Set match_conditions to ANY when you want an OR. The other frequent trap is testing a field that is empty at insert time: if a category or a configuration item is populated by a later step or by the fulfiller, the condition evaluates against a blank value when the engine runs. Test your query in a list view filter first and confirm real records come back.

Record producers, inbound email, and case records

Some intake channels behave differently. Record producers commonly map a group as part of the producer definition, which pre-populates assignment_group and short-circuits the rule. Incidents created from inbound email actions depend on what the email script sets. And Customer Service Management cases do not live on a task-derived incident table in the way people assume, so assignment rules written for incident will not carry over. When a rule works in the form and fails in production, look at how production records are actually created before you touch the rule.

A quick diagnostic table

Is there a round robin assignment rule in ServiceNow?

No. This is the gap that sends most admins looking for a script. Native assignment rules match conditions and set a group or a user, but they have no concept of rotation, so the same person can sit at the top of a group forever. The usual community build is a before insert or update business rule with its order set above 1000, so it runs after the assignment engine rather than being ignored by it, plus a way to remember who went last. Two patterns show up: a custom field or system property storing the last assigned user, or a query that counts open tasks per group member and picks the lowest. The second is closer to load balancing than to true rotation, and it is generally the better behavior.

It is worth repeating the caution experienced ServiceNow developers give on these threads: plain rotation makes no allowance for task type, current workload, sick leave, or operating hours. A counter that hands the next P1 to whoever is next in the alphabet, including the person on vacation, is not fairness. It is just evenly distributed harm. If you build it, gate the rotation on group membership plus an availability check at minimum, and expect to maintain the script every time the team changes.

ServiceNow assignment rules best practices

A few habits keep these rules stable. Keep one authoritative mechanism per table, because assignment rules, business rules, flows, and data lookup rules can all touch the same two fields and the result is only predictable if one of them owns the decision. Order rules from most specific to most general, since the first match wins and a broad rule near the top will swallow records meant for a narrower one below. Avoid dictionary defaults on assignment fields entirely, given that they silently disable every rule that follows. And write the condition against fields that are reliably populated at insert, not fields your fulfillers fill in later.

It also helps to know where the group and user records driving those conditions come from. Assignment quality depends on sys_user_group membership being current, and in most enterprises that membership is synced from an HR system or an identity provider on a schedule nobody is watching. When that sync half-fails, rules keep firing and keep assigning to a group that lost half its members, which reads as a routing bug for weeks. Being able to trace where those upstream records actually come from and when they last changed turns a mysterious assignment problem into a data problem you can fix at the source.

When to stop scripting and route beside ServiceNow

There is a point where the maintenance cost of a custom rotation script exceeds what it is solving. It usually arrives when you need three things at once: rotation that is genuinely fair, awareness of who is actually available, and an answer to "why did this ticket come to me" that does not require reading a script. Native rules give you the first only through custom code, and the third not at all. A routing layer that sits beside ServiceNow keeps the platform as your system of record while handling the assignment decision with rules you can read, including round-robin assignment weighted by current workload and gated on availability. Our ServiceNow routing alternative page compares the two approaches honestly, including where ServiceNow is the better answer.

If you are comparing how other help desks handle this, the differences are larger than most buyers expect. Zendesk includes native rotation on Suite plans, Freshdesk gates it to Pro and Enterprise, and Jira does it through an automation rule. Our breakdown of round robin ticket assignment across Zendesk, Jira, Freshdesk, and ServiceNow puts the plan gating and the limitations side by side. For the broader picture of routing a support queue by skill and load rather than by turn order, see support ticket routing.

Frequently asked questions

Can a ServiceNow assignment rule overwrite an existing assignment group?

No. If assignment_group or assigned_to already holds a value when the engine runs, the rule is skipped. This includes values set by a dictionary default, a template, a record producer, or an earlier assignment rule in the same save. To change an assignment that already exists you need a business rule or a flow, not an assignment rule.

What tables do ServiceNow assignment rules work on?

Only tables that extend task, such as incident, change_request, problem, sc_req_item, change_task, and sc_task, plus custom tables built on task. The engine is not invoked for non-task tables at all, so a rule defined against one will never run regardless of how the conditions are written. Use a business rule or a flow on those tables instead.

What business rule order should I use for round robin in ServiceNow?

Above 1000. Before business rules with an order below 1000 run ahead of the assignment engine, so a rotation script placed there sets a value that then blocks the assignment rules from running, or gets tangled with them. Setting the order above 1000 puts your script after the engine, which is where rotation logic belongs.

Why does my ServiceNow assignment rule script not work?

Most often because it is placed in the script field of a rule whose conditions never matched, or because the record was already assigned before the script ran. Confirm the rule matched by testing its encoded query as a list filter, check whether match_conditions is set to ALL when you intended ANY, and verify no earlier automation populated the assignment fields.

Does Advanced Work Assignment replace assignment rules?

Not exactly. Advanced Work Assignment is the supported way to route work by capacity and skill into Agent Workspace, and it handles the fairness problems assignment rules do not. It is a heavier implementation with its own service channels and capacity settings, so it makes sense for teams committed to Agent Workspace rather than as a quick replacement for a rule that stopped firing.