ServiceNow Assignment Rules Execution Order: What Runs When

ServiceNow assignment rules run inside the system engine block, which executes between before business rules ordered below 1000 and before business rules ordered 1000 or higher. The full save sequence is: before business rules under 1000, then the engines (assignment rules, approval rules, data policies, escalations, workflow, notifications), then before business rules at 1000 and above, then the database write, then after business rules under 1000, then after business rules at 1000 and above. Within the assignment rules themselves, the first rule whose conditions match at the lowest execution order wins, and no later rule runs. That one sequence explains almost every ordering surprise admins hit, and it is the lever you use to control precedence.

What is the execution order of assignment rules in ServiceNow?

Assignment rules are not business rules and they do not compete with them on a shared order number. They live in a separate stage of the save, the system engine block, and that block sits at a fixed point that you cannot move. What you can move is your own business rules, on either side of it. This is why the advice you keep reading is always phrased as an order number rather than as a setting: there is no checkbox that says "run after assignment," there is only a number above or below the threshold.

Here is the sequence in full, for a record insert or update.

ServiceNow save sequence, stage by stage

Why 1000 is the number that matters

The threshold is not arbitrary and it is not a convention someone invented on a forum. All of the system engine processing happens between the processing of rules at 999 and 1000. That single line is the whole rule, and everything else follows from it.

The practical consequence catches people out in both directions. If you want your script to run before assignment rules, so that it populates a category, a configuration item, or a location that your conditions depend on, give it an order below 1000. If you want your script to run after assignment rules, so that it can look at what the engine decided and adjust it, give it 1000 or higher.

Getting this backwards produces the classic symptom: an assignment rule that appears to do nothing at all. A before business rule ordered at, say, 100 that sets assigned_to directly runs at stage 1, so by the time the engine reaches stage 2 the record already has an owner. Assignment rules will not overwrite an existing assigned_to or assignment_group, so the engine skips the record entirely and every rule you wrote sits there looking correct and never firing. We covered that failure mode and its four siblings in detail in ServiceNow assignment rules not working.

Assignment rule execution order: lowest number wins, and only one fires

Inside the engine block there is a second ordering question, and it works differently from business rules. Assignment rules have their own execution order field, and the engine evaluates them from the lowest number upward. The first rule whose conditions match the record is applied, and evaluation stops there. Later matching rules do not run and do not stack.

Two habits follow from that. Order rules from most specific to most general, because a broad rule sitting at a low order will swallow every record that a narrower rule further down was meant to catch. And leave gaps between your order numbers, 100, 200, 300 rather than 1, 2, 3, so that inserting a more specific rule later does not mean renumbering the set.

It also means duplicate order values are a real risk. If two rules share the same execution order and both match, which one applies is not something you should be relying on. Give every rule on a table a distinct number.

Where data lookup rules sit, and the "Always replace" flag

Assignment data lookup rules are the other mechanism that writes to the same two fields, and they have their own order semantics that surprise people. New assignment data lookup entries default to an execution order of 100, so if you create several without changing that number you end up with a set of rules that all claim the same position.

The more consequential setting is the "Always replace" checkbox. With it unchecked, the lookup will not overwrite a field that already holds a value, which matches the behavior of assignment rules. With it checked, a later matching rule can overwrite what an earlier one set, which is how a more specific lookup is meant to beat a generic one. That flag is the difference between "first match wins" and "last match wins" on the same screen, and it is not obvious from the form.

The broader lesson is the one every experienced admin repeats: pick one authoritative mechanism per table. Assignment rules, assignment data lookup rules, before business rules, and flows can all set assignment_group, and the combined behavior is only predictable if exactly one of them owns the decision. When four mechanisms touch the same field, the execution order becomes something you have to reconstruct from scratch every time someone asks why a ticket went where it went.

Business rule order vs priority: they are the same field

A recurring point of confusion is whether a business rule has both an order and a priority. In the business rule form the field is Order, and it is what determines execution sequence within its stage. "Priority" is the word people carry over from other platforms or from the Priority field on task records, which is unrelated to execution. If you are looking for a priority setting on a business rule to make it run first, you want Order, and a lower number runs earlier.

Worth separating from this: on a task record, the Priority field is an output of Impact and Urgency and has nothing to do with when automation runs. Routing by that value is a different problem, and one worth solving deliberately rather than through rule ordering. We wrote about the tradeoffs in priority based ticket routing.

Ordering patterns that hold up

A few concrete patterns cover most real instances.

Feed the engine, do not fight it. If your assignment conditions depend on a derived value, compute that value in a before business rule ordered below 1000 and let the assignment rule read it. Do not compute the assignment itself down there.

Put rotation above 1000. ServiceNow has no native round robin assignment rule, so rotation is always custom. A before insert or update business rule ordered above 1000 runs after the engine has picked a group, which is exactly where a script that picks a person within that group belongs. Below 1000 and it either blocks the engine or gets overwritten by it.

Keep a written map. The reason ordering bugs take days rather than minutes is almost never the logic. It is that nobody can list what currently writes to assigned_to on a given table. In an instance with a few hundred business rules, several flows, and a decade of accumulated data lookup entries, that list lives partly in the platform and partly in wikis, runbooks, and old change tickets. Teams that can search across every internal system at once to find the one document that explains a rule resolve these far faster than teams reconstructing intent from the script field alone.

Test the condition as a filter. An assignment rule condition is an encoded query. Paste it into a list view filter on the same table and confirm real records come back before you conclude the ordering is wrong. A rule that never matches looks identical to a rule that runs too late.

When ordering is not the real problem

There is a point where you are not debugging execution order, you are maintaining a routing engine that ServiceNow was never asked to be. It usually shows up as a rotation script that has been patched five times, an availability check bolted on after someone came back from vacation to forty tickets, and no way to answer "why me" without opening the script.

Order gives you sequence. It does not give you fairness, skill matching, live workload awareness, or an explanation anyone outside the platform team can read. A routing layer beside ServiceNow keeps the platform as your system of record and handles the assignment decision with rules a service desk manager can edit, including round-robin assignment weighted by current workload and gated on who is actually on shift. Our ServiceNow routing alternative page compares the two honestly, including the cases where staying native is the right call.

If you are also weighing how other help desks handle this, the gap is wider than most buyers expect. Zendesk includes rotation on Suite plans, Freshdesk gates it to Pro and Enterprise, Freshservice splits it across two different frameworks, and Jira does it through an automation rule. Our comparison of round robin ticket assignment across eight help desks puts the plan gating side by side, and Freshservice ticket assignment covers the Freshworks side in the same detail.

Frequently asked questions

What is the order of execution for business rules in ServiceNow?

Before business rules with an order below 1000 run first, then the system engines including assignment rules, approval rules, data policies, escalations and workflow, then before business rules ordered 1000 or higher, then the database operation, then after business rules below 1000, then after business rules at 1000 and above. Within each group, a lower order number runs earlier.

Do assignment rules run before or after business rules in ServiceNow?

Both, depending on the business rule's order. Assignment rules run inside the system engine block, which sits between before business rules ordered below 1000 and those ordered 1000 or higher. So a before business rule at order 500 runs before assignment rules, and one at order 1100 runs after them. The engine block itself cannot be moved.

What does business rule order 1000 mean in ServiceNow?

It is the threshold that separates business rules running before the system engines from those running after. All system engine processing, including the assignment rule engine, happens between the processing of rules at 999 and 1000. Setting a before business rule to 1000 or higher is the supported way to make it run after assignment rules have already evaluated.

Which assignment rule runs if two rules match the same record?

The one with the lower execution order. The engine evaluates assignment rules from the lowest number upward, applies the first rule whose conditions match, and stops. Later matching rules never run. Order your rules from most specific to most general, and give each a distinct number so the outcome is never ambiguous.

Is business rule priority the same as order in ServiceNow?

Yes, in practice. The business rule form has an Order field and that is what controls execution sequence; there is no separate priority setting for execution. The Priority field people are thinking of lives on task records, is derived from Impact and Urgency, and has no effect on when automation runs.

Why does my business rule run but the assignment rule does not?

Almost always because the business rule is ordered below 1000 and sets assigned_to or assignment_group directly. Assignment rules will not overwrite an existing assignment, so once your rule has populated either field the engine skips the record. Either move the business rule above 1000 so it runs after the engine, or have it set the fields your conditions test rather than the assignment fields themselves.