What is a Business Rule in ServiceNow?

Why Business Rules exist

Imagine your company has a rule: “every Network incident must be assigned to the Network team.” You could ask every support agent to remember it. But people forget, new joiners do not know it, and on a busy day nobody checks. Within a week, some incidents are sitting with the wrong team.

A Business Rule solves this by moving the rule from people’s heads into the system. You write it once, and from then on ServiceNow applies it to every incidentIncidentA record describing something that is broken or not working for a user, like a laptop that will not connect to Wi-Fi.Learn more →, every time, no matter who creates it or how busy the day is.

Where Business Rules run

Business Rules are server-sideServer-sideCode that runs on ServiceNow's servers, not in the user's browser. Users see its effect, never the code itself.Learn more →. That means they run on ServiceNow’s own machines, not in the user’s browser. The user never sees your code; they only see what it does, such as a fieldFieldOne piece of information on a record, like an incident's Priority or Short description.Learn more → that filled itself in or a message that appeared after saving.

Because they run on the server, Business Rules work no matter how a record changes. Someone might edit an incident on its formFormThe screen that shows one record and lets you view or edit its fields.Learn more →, change it from a listListThe screen that shows many records of one table as rows, like a spreadsheet.Learn more →, import it from a spreadsheet, or another system might update it through an integration. In almost every case, the same Business Rule runs. That is what makes them so reliable for enforcing rules.

Finding Business Rules in your instance

Open your PDIPDI (Personal Developer Instance)A free ServiceNow instance you get from developer.servicenow.com to practise on safely.Learn more → and type Business Rules into the filter navigator on the left. Under System Definition, click Business Rules. You will see a long list: ServiceNow itself ships with hundreds of Business Rules, which already power much of how the platform behaves.

Open any one of them to see the Business Rule form. Every Business Rule, whether ServiceNow’s or yours, has the same parts.

The parts of a Business Rule

Field	What it means
Name	A clear name so you and others know what the rule does
Table	Which records the rule watches, such as Incident
Active	Whether the rule is switched on
Advanced	Tick this to write your own script
When	The moment the rule runs: before, after, async or display
Insert / Update / Delete / Query	Which actions trigger the rule
Filter Conditions	Only run the rule for records that match, such as “Priority is 1 - Critical”
Script	Your code, on the Advanced tab

The When field is so important that it gets its own lesson: it decides the type of the Business Rule. For now, the key idea is simple: the table says which records, the actions and conditions say for which changes, and the script says what to do.

Meet current and previous

When your script runs, ServiceNow hands it two things to work with.

currentcurrentIn a server script, the record being worked on right now, including any new values.Learn more → is the record being saved right now, with all its new values. If you want to read a field, you write current.priority; if you want to change one, you write something like current.short_description = 'Laptop not starting';.

previouspreviousIn a Business Rule, a copy of the record as it was before the current change.Learn more → is a copy of the same record as it was before this change. It lets you compare old and new. Suppose an agent changes an incident’s priority from 3 to 1 and clicks Save. Inside the Business Rule, previous.priority is 3 and current.priority is 1.

When a record is being created for the first time, there is no older version yet, so previous is empty.

Build your first Business Rule

Let’s build a rule that shows a reminder message whenever an incident becomes Priority 1. Follow along in your PDI:

1. Go to System Definition > Business Rules and click New.
2. Set Name to Remind on P1 incident.
3. Set Table to Incident [incident].
4. Tick Advanced.
5. On the When to run tab, set When to before, and tick Insert and Update.
6. Under Filter Conditions, choose Priority, changes to, 1 - Critical.
7. On the Advanced tab, put this inside the script:

(function executeRule(current, previous /*null when async*/) {
    gs.addInfoMessage('This incident is now Priority 1. Please make sure the right team is assigned.');
})(current, previous);

8. Click Submit.

Now test it. Open any incident, set Impact to 1 - High and Urgency to 1 - High (ServiceNow calculates Priority from these two), and save. A blue message appears at the top of the form. Save the same incident again without changing the priority, and the message does not appear, because the priority did not change this time.

What’s next

You now know what a Business Rule is, where it runs, how its form is laid out, and what current and previous mean. In the next lesson, Types of Business Rules, you will learn the four choices in the When field and exactly when to use each one.