What is a Business Rule in ServiceNow?
A Business Rule is a server-side script in ServiceNow that runs automatically when a record is inserted, updated, deleted, or queried in the database. Think of them as automated logic that lives on the server — they execute before the user sees any result, making them powerful for enforcing business logic, data integrity, and automation.
📌 Key distinction: Business Rules run on the server. Client Scripts run in the browser. This is one of the most common exam and interview questions on this topic.
The Four Types of Business Rules
| Type | When It Runs | Common Use Case |
|---|---|---|
| Before | Before the record is saved to the database | Validate data, modify field values before commit |
| After | After the record is saved | Update related records, trigger notifications |
| Async | After save, runs in background | Long-running tasks that shouldn't slow the UI |
| Display | Before the form loads (read-only) | Populate scratchpad variables for Client Scripts |
When to Use a Business Rule
- Setting a field value based on conditions (e.g., auto-set Priority = High if Category = Security)
- Preventing a record from being saved if validation fails
- Creating child records automatically when a parent is updated
- Logging changes to an audit table
- Triggering an integration or sending a notification after a record update
Writing Your First Business Rule
Navigate to Business Rules
Go to System Definition → Business Rules in the navigator. Click "New" to create one.
Set the Table
Choose which table this rule applies to — for example, Incident [incident]. The rule only fires on records in that table.
Choose the When
Select "Before" for validation/modification, "After" for triggering downstream actions. For beginners, start with "Before".
Set Conditions (Optional)
Use the Condition builder to limit when the rule runs — e.g., only when State changes to "Resolved". This keeps your rule efficient.
Write the Script
Enable "Advanced" mode to write JavaScript. Use the current object to access the current record's fields.
Real Example: Auto-Set Priority Based on Category
This "Before Insert or Update" Business Rule on the Incident table automatically sets Priority to 1 (Critical) when the Category is "Security":
if (current.category == 'security') {
current.priority = 1;
}
Simple, readable, and effective. The current object represents the record being saved. You can read and write any field on it.
Common Business Rule Mistakes (and How to Avoid Them)
Infinite Loops
A Business Rule that updates the same record it's running on can trigger itself repeatedly. Use current.setWorkflow(false) or add a condition to check if the update is necessary before making it.
Using "After" When "Before" Is Correct
If you need to modify a field value before it's saved, always use "Before". An "After" rule runs after the database commit — the value is already saved and you'd need a separate update.
No Conditions
A Business Rule with no conditions runs on every insert/update, which can significantly impact performance. Always add a condition unless you genuinely need it to run every time.
Business Rules vs Client Scripts vs Script Includes
| Script Type | Runs On | Access to DB | Best For |
|---|---|---|---|
| Business Rule | Server | Yes (direct) | Data logic, automation |
| Client Script | Browser | No (via GlideAjax) | UI interactions, field changes |
| Script Include | Server (reusable) | Yes | Shared functions, called by other scripts |
Next Steps
Once you're comfortable with basic Business Rules, move on to: using GlideRecord to query related tables, working with Script Includes for reusable logic, and exploring Flow Designer for no-code automation that complements Business Rules.
In the NowxLabs bootcamp, we write dozens of Business Rules across real sprint projects — so by the time you interview, these aren't theory, they're muscle memory.
Start Your ServiceNow Career Today
Join 500+ graduates who landed roles at TCS, CGI, Accenture and more through the NowxLabs 12-week bootcamp.
Apply for the Next Batch →