ServiceNow Business Rule Not Working? 8 Things to Check

A business rule that "does nothing" is one of the most common ServiceNow head-scratchers. The logic looks right, but the field never updates, the record never changes, or the rule seems to be ignored entirely. Nine times out of ten it's one of the following. Work through them in order.

1. Is the rule actually Active?

Obvious, but check first. Open the business rule and confirm the Active checkbox is ticked. If it was deployed via an update set that didn't capture the active state, it can arrive inactive.

2. Is the When value correct?

The When field decides everything about timing:

The classic mistake: setting a field on current in an after rule. By then the record is already saved — your change is lost unless you call current.update() (which you usually shouldn't). Setting current fields → use before.

3. Do the conditions actually match?

Check both the Condition field and the Filter Conditions builder. If either doesn't match the record, the rule won't run. Test with the condition temporarily cleared to confirm that's the blocker.

Also watch current.field.changes() vs current.field.changesTo(value) — a rule set to run only when a field changes won't fire on inserts where the value was set directly, depending on your setup.

4. current vs previous

Inside the script, previous holds the pre-change values (only meaningful on update, not insert). Comparing current.state != previous.state on an insert will behave unexpectedly because previous is empty. Guard with the operation:

(function executeRule(current, previous) {
  if (current.operation() == 'insert') { /* insert logic */ }
  else if (current.state.changes()) { /* update logic */ }
})(current, previous);

5. Is another rule overriding yours?

Business rules run in Order (ascending). A later rule (higher order number) can overwrite the field you just set. Check System Definition → Business Rules, filter by your table, and sort by Order. Space your orders (100, 200, 300) so you can insert rules between them later.

6. Are you editing the field the right way?

• Setting a field: current.setValue('field', value) or current.field = value.
• Don't call current.update() inside a before rule — it causes recursion.
• For reference fields, set the sys_id, not the display value.

7. Add logging and watch it run

Drop a log line at the top of the script and reproduce the action:

gs.info('MY RULE fired. state=' + current.state + ' op=' + current.operation());

Then check System Logs → System Log → All. No log line = the rule never ran (go back to When/conditions). Log line present but wrong values = your logic is the issue.

8. Client-side vs server-side confusion

If you expected a change to appear on the form without saving, a business rule won't do that — business rules are server-side and run on submit. For on-form, real-time behavior you need a client script or UI policy instead.

Quick triage checklist

• Rule is Active
• Correct When (before for current changes)
• Condition and Filter both match the record
• previous only used on updates
• No higher-Order rule overwriting the value
• gs.info confirms the rule fires
• Right tool for the job (business rule vs client script/UI policy)

When it's still a mystery

Some business-rule bugs come from interactions you can't see from one rule — recursive updates, setWorkflow(false), async ordering, or a global business rule on a parent table. If you've burned an afternoon on it, a second set of expert eyes usually finds it in minutes.