Business rules and advanced automation. When you submit a form on ServiceNow, someone needs to check the data, update another table, or send an email. Doing that manually for every single record would be slow and error-prone. Server-side automation solves this by letting the platform execute those checks and actions automatically, so the people using the system can focus on their real work.
Jump to a section
A simple way to picture Business Rules and Advanced Automation
A head chef runs a busy restaurant kitchen. Every time a waiter brings in a new order, the chef doesn't just start cooking blindly. Instead, they follow a written recipe card pinned to the counter. That card says: if the order is a steak, sear it for three minutes then grill it; if it's a pasta, boil the water first then add the noodles. The recipe card is a set of instructions that runs automatically whenever a specific type of order arrives.
In ServiceNow, a business rule is exactly that recipe card. The waiter is the user or another system submitting a record. The recipe card itself is the business rule, which the system executes automatically at the right moment, like 'before saving' or 'after updating'. The chef never needs to memorise every step because the card handles the logic. If the chef wants to change how a steak is cooked next time, they just update the card. Similarly, an administrator writes or edits a business rule to change how the platform behaves without rewriting the whole application. This is advanced automation. Instead of a human repeating the same steps manually, the system does it automatically, every time, with no mistakes.
Business rules are the most common type of server-side automation in ServiceNow. Think of them as scripts or sets of instructions that ServiceNow runs automatically when a record is inserted, updated, deleted, or queried. They live on the server, not in your browser, which means they run reliably no matter what device a user is on.
Every business rule has a trigger. You configure when the rule should fire: before the record is saved to the database, after it is saved, when a user is viewing the record (display), or when the record is being deleted. The 'before' type is special because the changes your script makes are saved along with the record. The 'after' type is used for side effects, like sending a notification or updating another record.
A business rule also has conditions. You can make it run only when certain criteria are met, for example only when the priority field is 'Critical' or only when the record belongs to a specific category. This prevents the rule from running unnecessarily and slowing things down.
To write a business rule, you use server-side scripting, typically JavaScript with access to special ServiceNow objects like 'current' and 'previous'. The 'current' object represents the record the user is working on. The 'previous' object represents the old values before the current update, which is only available in 'after' update rules. You use these to read, compare, and set field values.
Advanced automation extends beyond business rules to include scheduled jobs. A scheduled job is like an alarm clock that goes off at a specific time or interval. For example, every night at 2 a.m., ServiceNow could automatically archive old records or recalculate totals. Scheduled jobs are essential for housekeeping, reporting, and maintaining data quality without human intervention.
There are also script actions, which are reusable pieces of code you can call from multiple rules, and flow designers, which let you build automation visually without writing code. But the SNOW-CSA exam focusses on understanding when to use a business rule versus a scheduled job versus other automation tools.
Why does automation exist? Before platforms like ServiceNow, an IT professional might have to manually check every new request, update a spreadsheet, or send individual emails. Automation replaces that repetitive human effort with consistent machine execution. It reduces errors, speeds up processes, and ensures compliance because the rules run the same way every time.
Here are the key characteristics that define business rules:
They run on the server side, not on the user's browser.
They are triggered by database operations: insert, update, delete, or query.
They can run before or after the database operation.
They have conditions to control when they execute.
They can be ordered to ensure they run in a specific sequence.
Scheduled jobs differ in a few important ways:
They are triggered by time, not by a user action on a record.
They run at defined intervals like daily, hourly, or once.
They are best for background maintenance and bulk operations.
The SNOW-CSA exam tests your ability to choose the right tool for the job. For example, if you need to send an email whenever a ticket is closed, a business rule (after update) is the correct choice. If you need to run a report every Sunday, you need a scheduled job.
Identify the trigger type
Decide whether the rule should run before the record is saved, after it is saved, when it is displayed, or when it is deleted. This choice dictates what data is available and whether changes are automatically saved.
Define the condition
Write a condition that limits the rule to only execute for relevant records. For example, only run the rule when the 'state' field equals 'Closed'. This prevents unnecessary script execution and improves performance.
Write the script
Use JavaScript with the 'current' object to read and modify fields. Avoid expensive operations like GlideRecord queries inside before rules to keep the system fast. Stick to simple field assignments and calculations.
Set the order
Assign a numeric value in the 'order' field. This determines the sequence if multiple business rules run on the same table. A rule with order 10 runs before a rule with order 20.
Test the rule
Create a test record that meets the condition. Submit the record and verify the expected field changes occurred. Check the system logs if the rule does not behave as expected.
Activate the rule
Set the 'Active' checkbox to true. Only active rules run. Inactive rules are ignored but can be enabled later without rewriting the script.
Imagine you work for a medium-sized company that uses ServiceNow to manage IT support tickets. Every time an employee submits a new password reset request, the IT team wants to automatically assign it to the right technician based on the employee's location. Without automation, someone would have to read each request, look up the location, and then manually assign it. That takes time and risks mistakes.
As an administrator, you create a business rule that runs 'before' the record is saved. The condition checks the 'category' field equals 'Password Reset'. Inside the script, you read the 'location' field from the current record, then use an if-else statement to set the 'assigned_to' field to the appropriate group or technician. The system does this instantly for every new ticket.
Next, consider the monthly process of generating a compliance report. You need to aggregate all closed tickets from the previous month, calculate average resolution time, and email the results to management. Doing this manually on the first of each month is tedious. Instead, you create a scheduled job that runs at 8 a.m. on the first day of every month. The job uses a GlideAggregate to query the database, calculates the required metrics, and sends an email via a script.
Another practical scenario involves data quality. Suppose users often enter inconsistent values in a 'state' field, like 'in progress', 'in-progress', or 'In Progress'. You write a business rule that runs 'before' insert or update. It normalises the input by converting it to a standard format. This prevents reporting errors later.
Here is a step-by-step workflow an administrator follows when building a business rule:
Identify the trigger: when should the rule run? (before save, after save, etc.)
Determine the condition: what records should trigger it? (e.g. only when priority is 1)
Write the script: use JavaScript with GlideRecord or current.update() as needed.
Order the rule: if multiple rules run on the same table, ordering ensures the correct sequence.
Test the rule: create a test record and verify the expected behaviour.
Set the rule to active: only active rules execute.
In larger organisations, you might have dozens of business rules on the same table. Without careful design, performance can suffer. That is why experienced administrators write efficient scripts, avoid heavy database queries inside before rules, and order rules so the most important ones run first.
The SNOW-CSA exam dedicates a specific set of questions to business rules and advanced automation. You will not be asked to write a full script, but you must understand the concepts, the order of execution, and the correct use cases.
Here are the exact concepts they test:
Business rule types: before, after, display, and delete. They love to ask which type to use for a given scenario.
The 'current' and 'previous' GlideRecord objects. Questions often ask what data is available in a before-update rule versus an after-update rule. The correct answer is that 'previous' is only available in after-update rules.
Conditions vs. filters: you must know that conditions are evaluated on the server and can include complex logic, while filters are for limiting which table the rule applies to.
Ordering: rules execute in ascending order based on the 'order' field. If two rules conflict, the lower-numbered rule runs first.
The difference between business rules and scheduled jobs. A common trap question: 'You want to send a notification when a ticket is closed. What do you use?' The wrong answer might be 'scheduled job' because a new student thinks of email as a batch process. The correct answer is a business rule (after update).
Traps the exam sets:
They give a scenario where a rule needs to run 'when the user opens a form'. The naive answer is 'before' or 'after' update. The correct answer is 'display' business rule, which runs when the record is loaded for viewing.
They ask: 'What happens if a before business rule modifies a field?' The correct answer: the change is saved automatically with the record. The trap is thinking you need to explicitly save the record inside the rule.
They ask: 'Which automation runs even if no user is logged in?' The correct answer is a scheduled job. A business rule requires a user action to trigger.
Key definitions to memorise:
Business rule: server-side script triggered by database operations.
Scheduled job: time-based script run by the system scheduler.
Script action: reusable server-side script invoked by business rules or events.
Current: the GlideRecord object holding the record being processed.
Previous: the GlideRecord object holding the record's values before the current update (only in after rules).
You will also face questions about the 'order' field and the 'active' checkbox. A rule with order 100 runs before a rule with order 200. An inactive rule is ignored entirely. The exam expects you to know that business rules belong to a table, and you navigate to them via System Definition > Business Rules in the application navigator.
Business rules are server-side scripts that run automatically when a record is inserted, updated, deleted, or queried.
The 'before' business rule runs before the record is saved, and any changes made in it are saved automatically.
The 'previous' object is only available in 'after' update and 'after' delete business rules.
Scheduled jobs are triggered by time, not by user actions, and are used for background maintenance tasks.
Business rules can be ordered using the 'order' field; rules with a lower number execute first.
Use a 'display' business rule when you need to modify data right before a user views a record.
An inactive business rule does not run at all, even if its conditions are met.
These come up on the exam all the time. Here's how to tell them apart.
Before Business Rule
Runs before the record is saved to the database
Changes made via script are automatically saved
'previous' object is not available
After Business Rule
Runs after the record has been saved
Used for side effects like emails or updates to other tables
'previous' object is available to compare old and new values
Business Rule
Triggered by a user action on a record (insert, update, delete, query)
Executes immediately in response to the action
Runs as part of the user's transaction
Scheduled Job
Triggered by time (e.g. daily, hourly, once)
Executes at a predefined schedule
Runs in the background, independent of user actions
Display Business Rule
Runs when a record is loaded for viewing
Cannot stop the record from being saved
Used for visual modifications or warnings
Before Business Rule
Runs when a record is being saved
Can stop the save with setAbortAction()
Used for validation and data transformation
Script Action
A reusable script that can be called from multiple rules or events
Not tied to a specific table
Must be manually invoked by a business rule or event
Business Rule
Tied to a specific table and trigger
Runs automatically when conditions are met
Self-contained for a single automation purpose
Mistake
Business rules run on the user's browser, similar to client scripts.
Correct
Business rules run on the server side. Client scripts run in the user's browser. They are different tools for different purposes.
The word 'rule' sounds like something that governs behaviour on the screen, so beginners assume it is client-side. The distinction is critical for performance and security.
Mistake
You can use 'previous' in a before-update business rule to see what the old value was.
Correct
The 'previous' object is only available in after-update and after-delete business rules. In a before rule, you can only see the current values.
This is a subtle detail that is easy to miss during study. Many practice exams specifically test this point to catch candidates who did not read the documentation carefully.
Mistake
Scheduled jobs run immediately when you create them.
Correct
Scheduled jobs run only at their defined scheduled time or interval. They do not run instantly upon creation unless you manually execute them via the 'Execute Now' button.
Beginners think of scheduled jobs like a button you press. In reality, they are time-based and require the system scheduler to be active.
Mistake
A business rule can only be created by a developer who knows JavaScript.
Correct
While writing a business rule requires scripting knowledge, many business rules can be configured using conditions and actions without any code, especially using the Flow Designer. The CSA exam covers both scripting and no-code approaches.
The platform has evolved to include low-code tools, but older study resources still assume all automation requires coding. New learners need to know that visual automation is also an option.
Mistake
Ordering business rules does not matter because they all run at the same time.
Correct
Business rules execute in ascending order based on the 'order' field. The order determines which script runs first, which can affect the final state of the record.
This misconception arises because beginners have not encountered race conditions in scripts. The exam tests this by asking which rule executes first in a given sequence.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A business rule runs on the server side and can change data before it is saved. A client script runs in the user's browser and can only manipulate what the user sees on the screen, not the database directly.
Yes. In a 'before' business rule, if you set the 'current.setAbortAction(true)' method, the record will not be saved. This is used to enforce validation rules.
Use a scheduled job when you need to perform an action at a specific time or on a repeating schedule, not in response to a user action on a record. For example, nightly data clean-up.
Navigate to System Definition > Business Rules in the application navigator. You can search by table name or filter by type.
A display business rule runs when a record is loaded for viewing. It can modify field values or add messages before the user sees the form.
Yes, you can have many business rules on the same table. They run in order based on the 'order' field, so you can control the sequence of execution.
You've finished Business Rules and Advanced Automation. Continue through the SNOW-CSA study guide to build a complete picture of the exam.
Done with this chapter?