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.

Let the ServiceNow Agent run this triage for you

Working through eight checks by hand is fine once — tedious the tenth time. The NovusAI ServiceNow Agent can do it on your own instance: connect your ServiceNow developer instance and ask something like "Why isn't my 'Set Priority' business rule on incident firing?" It reads the rule, checks the When value, order, and conditions, looks for a higher-order rule overwriting your field, and adds logging to confirm whether it runs — then tells you the cause in plain English. With your approval it can apply the fix and query the record back to verify it worked. It's read-only until you enable writes, and it pauses for your approval on every change. See how it works.

How the NovusAI agent does this

Every check above is a record lookup, which is exactly the kind of tedious, high-context work the agent is built for. Connected to your instance, it can:

• List the rules on the table and show when, order, active and the condition side by side — the four fields that explain most "it isn't firing" cases — without you opening nine forms.
• Read the rule itself and reason about current vs previous, whether a before rule is being used where an after is needed, and whether an order collision means another rule is overwriting your value.
• Check what else touches the field, since a business rule that "does nothing" is often being undone by a second rule, a UI policy, or a data policy further down the order.
• Write the fix — create or update the rule — and show you the exact record and script it will apply first. Nothing is written until you approve it.

Ask it plainly: "My business rule on incident that sets priority isn't firing — find out why." It will investigate the real records on your instance rather than guess from a description.