ServiceNow Assignment Rules: Table, Script, Execution Order, and Auto Assignment

What is an assignment rule in ServiceNow, and what table are assignment rules stored in?

An assignment rule is a small piece of platform configuration that says "when a task record looks like this, put it on that group". It is not a workflow, not a business rule, and not a script include, although it can call script. Every rule lives as one record on the sysrule_assignment table, and you reach the list in the platform UI under System Policy, then Rules, then Assignment. Knowing the table name is more useful than knowing the menu path, because it is what lets you query the rules, export them, compare two instances, or check whether an update set actually brought a rule across. A rule carries ten fields and each one changes the outcome. Name is a label capped at 40 characters, which is short enough that teams end up with rules called "Network 2" and no idea what they do, so the description field, capped at 4000 characters, is worth filling in properly. Table names the target and must extend task. Active defaults to true. Condition is an encoded query capped at 1000 characters, built in the standard condition builder. Match conditions decides whether all of those conditions must be true or any one of them, and it defaults to ALL, which is the setting people forget when a rule with four conditions never fires. Group holds a sys_id from sys_user_group and user holds one from sys_user; prefer the group, because a named individual bakes a staffing assumption into your routing that is false the moment that person takes a week off. Script is server-side JavaScript capped at 8000 characters, where current is the record being saved. And order is the execution order, defaulting to 100, with lower numbers evaluated first.

How do you write a ServiceNow assignment rule script, and when do you need one?

Most rules never need script. If the answer is "priority 1 network incidents go to Network Operations", the group field and a condition are the whole rule and adding script only adds something to maintain. The script field earns its place when the group cannot be known until the record is read: routing by a lookup on the caller's location, by a field on the affected configuration item, by the manager of the requesting department, or by a value that has to be derived rather than matched. The mechanic is straightforward. When the rule matches, the platform checks whether the group field is populated; if it is, the assignment is made directly, and if it is not, the script runs and is expected to set the assignment itself, typically with current.assignment_group = someSysId; using current as the record being saved. Two habits keep script-based rules from becoming the thing nobody wants to touch. First, resolve the group by a stable lookup rather than a hardcoded sys_id, because sys_ids are one of the more common reasons a rule works in development and silently assigns nothing in production. Second, guard for the empty result: if your lookup returns nothing, decide deliberately whether to leave the field empty and let a later rule catch it, or to fall back to a service desk group, because a script that sets an empty value gives you the worst outcome, a record that looks routed and is not. It is also worth knowing that assignment rules cannot be triggered on demand from script the way a Salesforce assignment rule can be attached to a DML call. If you need assignment logic that other automation can call, the platform answer is a script include or a subflow that both the rule and the caller use. There is one more behavior worth knowing before you write anything: ServiceNow's SDK guidance warns that when a rule has a script, the script silently overrides whatever sits in the group and user fields, so a rule configured with both is not doing what its form appears to say. Working assignment rule script examples and the reasons a script quietly does nothing covers that, the hardcoded sys_id trap, and the threshold where the logic should move to a business rule.

What is the execution order of assignment rules in ServiceNow?

There are two different questions hiding in that phrase, and mixing them up is the source of a lot of confused troubleshooting. The first is order among assignment rules. Rules on the same table are evaluated from the lowest order number upward. For each rule, the condition is checked against the record, and the first rule whose condition matches performs the assignment and evaluation stops. The platform does not look for the best match or the most specific condition; it takes the first true one. That means specificity has to be expressed through the order number, not through how detailed the condition is. Put your narrow exceptions at order 100 or below and your broad catch-alls at 500 or higher, leave gaps of at least 50 between rules so you can insert one later without renumbering everything, and treat the default of 100 as a value to change rather than accept, because a set of rules all sitting at 100 resolves in an order nobody controls. The second question is where assignment rules sit in the save sequence relative to everything else. The order is: before business rules with an order below 1000, then system engine processing, then before business rules at 1000 or above, then the database operation, then after business rules. Assignment rules and data lookup rules both run inside that system engine block, which is why the standard guidance is that all system engine processing happens between the processing of rules at 999 and 1000. The practical consequence: a before business rule ordered below 1000 that sets an assignment group will beat every assignment rule on the table, because by the time the rules run the field is no longer empty. If your rules stopped firing after somebody added a business rule, that ordering is where to look first. The full save sequence and how to order rules deliberately goes through it step by step.

Why are ServiceNow assignment rules not working? The causes that account for almost all of it

Start with the one that explains more cases than everything else combined: assignment rules do not overwrite an existing value. If assignment group or assigned to already holds something when the rule is evaluated, the rule is skipped. Not logged as failed, not flagged in any way, just skipped. This is by design and it is also why a rule that clearly works on brand new tickets appears completely dead when you test it by editing an existing incident. If you need reassignment behavior, an assignment rule is the wrong tool and a business rule or a flow is the right one. The second cause is the table. Rules only run on tables that extend task. A rule pointed at a CMDB table, a user table, or any custom table that was created standalone rather than as a task extension will never run, and nothing warns you when you save it. Third is match conditions, which defaults to ALL. A rule with four conditions intended as alternatives fires only when all four are true at once, which in practice is never. Fourth is order collisions: two rules whose conditions both match, both sitting at the default order of 100, and the one you did not expect wins. Fifth, and increasingly relevant, is that something else got there first. Data lookup rules run in the same system engine block and, unlike assignment rules, they have an Overwrite existing values option, so a lookup rule can legitimately replace what your rule set. A before business rule ordered below 1000 beats the rules outright. An inbound email action can set the group as it creates the record. And on recent releases it is worth actually checking whether the out of box rules are even switched on: on a Zurich family instance, the shipped incident assignment rules were observed to be inactive, with the equivalent logic living in Flow Designer subflows named things like "Assign to shift member - Subflow" and "VIP Callers - Subflow". If you inherited an instance and the rules look empty or dormant, the routing may simply have moved. One last cause worth naming because it wastes whole afternoons: client scripts and UI policies never see records created by email, by the API, by an integration, or by an event. If your assignment logic lives client side, it works for everyone typing into a form and for nobody else. The full troubleshooting walkthrough for rules that do not fire covers each of these with what to check.

Can ServiceNow assignment rules do round robin, and what to do about the part they cannot?

No, and it is worth being precise about why, because the gap is structural rather than a missing checkbox. An assignment rule is a filter that resolves to a fixed answer. It reads the record in front of it, matches a condition, and sets a value. Round robin needs something the record does not contain: the memory of who received the last one. There is nowhere on a rule to keep that, so every native rotation in ServiceNow is built somewhere else, either with a counter in a system property that a business rule increments, or by moving the decision to Advanced Work Assignment, whose Last Assigned strategy offers work to whichever eligible agent has gone longest without an assignment. AWA is a genuinely good answer if you hold an ITSM, CSM, or HRSD subscription and your agents work in a workspace with the Agent Inbox, and it is not available to you otherwise. The same limit applies to the three things teams usually want next to rotation. Rules cannot see workload, so the person holding nine open priority 2 incidents keeps drawing new ones alongside everyone else. They cannot see availability, so a group with two people on annual leave routes exactly as it did when everyone was in. And they cannot express weighting, so a half-time engineer and a full-time one are treated identically, and the only native lever is to remove somebody from the group entirely. That is the boundary Assigner works on, beside ServiceNow rather than instead of it. Rules keep doing what they are good at, deciding which group owns which kind of work, and Assigner decides the person: round-robin assignment with real rotation state, workload balancing that counts open work rather than records, skills-based routing, and availability routing that respects working hours and time zones, applied to support ticket routing, sales leads, and ops tasks through one engine at $12 per user per month. Every assignment records the rule it used and the candidates it considered. Our honest comparison against native ServiceNow assignment sets out where staying native is the right call, because for criteria-shaped routing on a licensed ITSM instance it frequently is. Assigner is a companion rather than a live two-way sync, and it is built to help rather than to guarantee an outcome.

What are assignment rules in ServiceNow?

Assignment rules automatically set the assignment group, the assigned to user, or both on a task record when it is created or updated. Each rule pairs a condition with a target group or user, and an optional script for cases where the group has to be derived rather than named. They are the simplest native way to get a ticket onto the right team without writing a business rule or building a flow.

What table are ServiceNow assignment rules stored in?

Assignment rules are stored on the sysrule_assignment table. In the platform UI you reach them under System Policy, then Rules, then Assignment. Querying the table directly is more useful than the menu when you need to compare two instances, confirm an update set moved a rule across, or find every rule pointed at a group you are about to retire.

Why are my ServiceNow assignment rules not working?

The most common reason by a wide margin is that the record already has an assignment group or assigned to value, because assignment rules never overwrite an existing assignment and are silently skipped instead. After that: the target table does not extend task, match conditions is set to ALL when you meant ANY, two rules collide at the same order number, or a before business rule ordered below 1000 set the field first.

Do ServiceNow assignment rules overwrite an existing assignment group?

No. If assignment group or assigned to is already populated when the rule is evaluated, the rule does not run and nothing is logged. This is deliberate, so that automation never quietly takes a ticket away from the person working it. If you need reassignment on update, use a business rule or a Flow Designer flow instead, both of which can overwrite whatever is there.

What is the execution order of assignment rules in ServiceNow?

Rules on a table are evaluated from the lowest order number upward, and the first rule whose condition matches performs the assignment and stops evaluation. There is no best match logic. Within the wider save sequence, assignment rules run inside system engine processing, which happens after before business rules ordered below 1000 and before those ordered 1000 or above.

What is the default order for a ServiceNow assignment rule?

The order field defaults to 100. Leaving several rules at the default is a common cause of unpredictable routing, because when two rules both match, the winner is decided by something other than your intent. Give narrow exceptions lower numbers, give catch-alls higher ones, and leave gaps of at least 50 so a new rule can be inserted without renumbering the set.

How do you write a ServiceNow assignment rule script?

Leave the group field empty so the script is used, then write server-side JavaScript in the script field, where current is the record being saved and the usual pattern is to set current.assignment_group to a sys_id you have looked up. Resolve that group by name or by a reference rather than hardcoding a sys_id, and handle the case where the lookup returns nothing, or the rule will assign an empty value.

What is the difference between an assignment rule and a data lookup rule in ServiceNow?

An assignment rule pairs a condition with one fixed group or user and will not overwrite an existing value. A data lookup rule matches input fields such as category, subcategory, location, or configuration item against rows in a lookup table and returns the assignment group, and it can overwrite an existing value when the Overwrite existing values option is enabled. Lookups scale better for large matrices; rules are simpler and can use script.

Can ServiceNow assignment rules do round robin?

No. An assignment rule resolves to a fixed group or user and keeps no memory of who received the previous ticket, which is exactly what rotation requires. Native rotation means either a counter maintained by a business rule or Advanced Work Assignment, whose Last Assigned strategy offers work to the eligible agent who has gone longest without an assignment. AWA needs an ITSM, CSM, or HRSD subscription.

Do ServiceNow assignment rules work on custom tables?

Only if the custom table extends task. Assignment rules are a task table feature, so a standalone custom table created without that extension will never trigger a rule, and the platform gives no warning when you save a rule against one. If the table cannot be reparented, use a business rule or a record-triggered flow to set the assignment group instead.

How do you set up auto assignment in ServiceNow?

Decide the group first, then pick the lightest mechanism that expresses it. A small set of clear conditions belongs in assignment rules. A large matrix of category and location combinations belongs in a data lookup rule. Assignment derived from the configuration item is already handled by the shipped Populate Assignment Group based on CI business rule. Choosing the person inside the group needs Advanced Work Assignment or a routing layer beside the platform.