ServiceNow Business Rule Explained

What a Business Rule Is

A Business Rule in ServiceNow is a piece of logic that executes when a record in a specific table is created, updated, or read. It is similar to a database trigger in other systems. You write a Business Rule when you want something to happen automatically based on record changes, without requiring a user to take action. Examples include: setting a default value when an incident is created, preventing a record from being saved if certain conditions are not met, updating related records when a parent record changes, or sending a notification when a field reaches a threshold.

Business Rules are distinct from workflows, which are more visible to users and have multiple steps. A Business Rule is fast and silent: it runs, makes changes, and the user sees the result without knowing the rule executed. A workflow, by contrast, moves a record through visible steps with explicit user approval points.

Where Business Rules Live in the Platform

Business Rules are defined in the System Definition module, in a table called sys_script. You access them through System Definition > Business Rules. Each Business Rule specifies a target table, when it should run (before insert, after insert, before update, after update, or on read), and the conditions when it should execute. The condition is a query: run this rule only if a certain condition is true.

The logic of the rule is written in server-side JavaScript, which has access to the current record being changed and can query other tables or make API calls. The rule runs on the platform server, not in the user’s browser, so it has access to database queries and platform APIs that the user might not.

A Worked Example

Consider a scenario: when an incident is assigned to an assignment group, we want to notify the group manager immediately. You would create a Business Rule on the Incident table, set it to run after updates, with a condition that the assignment_group field has changed. In the rule logic, you query the users table to find the group manager, then send a notification using the GlideNotification API. The rule executes silently in the background whenever an incident is reassigned.

Another example: when a change is approved, populate the deployment start date with tomorrow if it has not been set already. Create a Business Rule on the Change table, run on after update when approval_status becomes approved. In the rule, check if the deployment start date field is empty, and if so, set it to a calculated value. This prevents users from forgetting this step.

Common Misunderstandings

A common misconception is that Business Rules can do anything. In reality, they are limited to server-side JavaScript capabilities and cannot access the user’s local file system or interact with the browser directly. They can query tables and call APIs, but very slowly running rules will time out. Rules that loop endlessly or call external APIs hundreds of times may impact platform performance.

Another misunderstanding is that Business Rules are the place to put all your customization logic. Business Rules are best used for simple, focused logic that must run automatically on record change. Complex business logic involving many steps is better implemented as a workflow or as a script include called from multiple places. If you find yourself writing long, complex Business Rules with many conditions, consider refactoring into a workflow or a script library.

Performance and Best Practices

Business Rules run on every matching record change, so they directly affect how long it takes users to save records. Write rules that run fast. Avoid querying large tables or looping through hundreds of records in a rule. If you need to do complex work triggered by a record change, consider using an asynchronous approach: the Business Rule sets a flag or creates a queue entry, and a scheduled job or workflow handles the actual work later.

Use the condition field generously. If your rule only applies when certain fields are present or certain values are set, use the condition to prevent the rule from even running. This is faster than running the rule and checking conditions in JavaScript. Disable or delete rules that are no longer used; dead code is confusing and may affect performance.

Debugging and Troubleshooting

When a Business Rule is not doing what you expected, enable execution of the rule and view the Business Rule Executions log. You can see whether the rule ran, how long it took, and whether it returned errors. Add logging statements in your rule logic using gs.log or gs.addInfoMessage to output debugging information. These logs appear in the execution log and help you understand what the rule did.

If a Business Rule is causing performance issues, the Business Rule Executions log will show which rule is slow. At that point, you can optimize the rule or move the logic elsewhere. If a rule is causing unexpected data changes or conflicts with other rules, check the rule order. Rules execute in the order they are displayed in the system, so if two rules modify the same field, the one that runs last wins.

Deciding whether a business rule is the right mechanism

Platform developers reach for a business rule whenever a record must change without a person pressing a button. That instinct is often right, but the same outcome can be produced by a flow, a client script, a UI policy or a scheduled job, and each choice carries different costs. A business rule runs on the server, on every matching write, including writes that come from imports, integrations and other scripts. That breadth is its strength for data integrity and its weakness for anything slow or conditional on a user’s screen.

Ask three questions before writing the rule. Must the logic run even when the change comes from outside the user interface? Does the outcome need to be visible to the user as a process step with approvals? Will the work take long enough to affect the save? A no to the first question points toward a client-side mechanism. A yes to the second points toward a flow. A yes to the third points toward a queued job that the rule only triggers.

Comparing the mechanisms before you build

A common design error is to put a multi-step approval into a business rule because it is convenient to write there. The rule then runs in the middle of a save, cannot pause for a person, and makes the process invisible to anyone reading the workflow history. Move that logic to a flow and keep the rule for the small, immediate change it needs to make.

A review sequence before a rule reaches production

1. Write the condition first, so the rule exits early for records it does not need to touch. Evaluate the condition on the field values that are cheapest to read.
2. Name the rule so its table, timing and purpose are visible in a list of many rules.
3. Check whether any field the rule writes can trigger another rule on the same table, and trace the chain to its end.
4. Run the rule against a copy of representative data, including imported records, and confirm the result matches the requirement.
5. Confirm the rule behaves correctly when a required reference is empty, because a null lookup is a common source of error in production.
6. Record the rule’s owner and purpose in its description, and add it to the list reviewed when the table’s design changes.

Failure modes that appear after deployment

• Recursive updates, where a rule changes a field that fires the same rule again, until a guard condition stops the loop. Every rule that updates its own table needs an explicit guard.
• Silent overwrites, where two rules set the same field and the one running later wins, so the value depends on execution order that nobody documented.
• Slow saves caused by a lookup inside a loop over related records, which is invisible in testing with small data and obvious only when the table grows.
• Rules that run on import and create side effects, such as notifications, for thousands of records at once.

When a rule seems to do nothing, check the execution log before editing the script. The log shows whether the condition was met, how long the rule took, and whether it errored. Many apparent bugs are conditions that never matched the data that actually arrives.

What a healthy rule set looks like

A healthy set of business rules on a table is short enough that a developer can read its order of execution in an afternoon. Each rule has one job, a documented owner, and a condition that narrows it to the records it serves. If a table carries rules that nobody can explain, the cost can show up as slow saves and unexplained field values, long before anyone blames the rules.

Do not write a business rule when the requirement is a reusable calculation used across many forms and processes. Put the calculation in a script include and call it from the rule, the flow, and the scheduled job alike. That keeps one definition of the logic and makes testing practical.

Can a business rule call an outside service?

It can, but a synchronous call inside a save makes the user wait on that service and fails the save if the service is down. Where the outcome can arrive later, queue the request and let a separate process send it.

Which runs first, a business rule or a client script?

The client script runs in the browser before submission, and the business rule runs on the server after it. The server rule is the one that protects data, because a browser check can be bypassed.

Should disabled rules be deleted?

Remove rules that are permanently obsolete after their behavior is confirmed to be unneeded, and keep a record of what they did. A disabled rule that no one remembers is a trap for the next developer.

How do I know which rule changed a field?

Use the field history and the execution log together. The history shows that a value changed and when, while the log shows which rules ran during that save.

Next step

If saves have become slow or field values cannot be explained, a review of the rule set and its order can find the source. For the governance side, for ownership and performance review, see the business rule governance article, and for sharing logic between rules, see the script include guide.