How do you ensure that bad data never gets saved to your database, and how do you make the system automatically do work for you after something is saved? This chapter solves both problems, explaining the two most powerful server-side tools you will use as a ServiceNow developer: Data Policies for data integrity and Business Rules for automation.
Jump to a section
A simple way to picture Business Rules and Data Policies
A lease agreement is the foundational contract between a landlord and a tenant. It sets out the core rules that are always true: rent is due on the first of the month, noise must be kept down after 10 PM, and no pets are allowed without written permission. These rules are like Data Policies in ServiceNow — they are the unchangeable, permanent checks that ensure the basic integrity of the data the moment a tenant (user) tries to sign the lease (submit a record). The lease agreement itself is the set of conditions that must be true for the signature to be valid.
But a landlord also needs to manage the building dynamically. When a tenant reports a maintenance issue, the landlord has a set of automated responses. If a tenant submits a report about a leaking tap, the system automatically creates a work order, assigns it to a plumber, and sends an email confirmation. This automated response is a Business Rule — it reacts to what just happened (the submission of the report) and triggers a sequence of server-side actions. The lease data policy prevents a tenant from signing with an invalid date. The maintenance business rule ensures that after the report is saved, the right people get notified and the right tasks get created. One is a fixed gatekeeper at the point of entry; the other is a reactive automation that executes after the data is already in the system.
In ServiceNow, the system processes data in a specific order when a user saves a record. Understanding this order is critical for passing the SNOW-CAD exam and for writing code that works correctly. A Data Policy is a server-side rule that runs before a record is saved to the database. Its only job is to check the values of fields on the form and either allow the save to proceed or block it. If a Data Policy fails — for example, if the user leaves a mandatory field blank — the system shows an error message and the record is not saved. Data Policies are the first line of defence for data quality. They are simple to create because they use a graphical user interface (GUI) — you do not need to write a single line of code. You just select the table, define the conditions (e.g., "when the status is 'Complete', the 'Resolution Notes' field is mandatory"), and the system enforces it automatically. Data Policies are always evaluated before any other server-side code runs. They are triggered on three operations: before a record is inserted (created), before a record is updated (changed), and before a record is deleted. However, they cannot access the old values of the record — they only see the new values the user is trying to save. This is a key exam distinction.
A Business Rule is a script that runs on the server in response to a database event. Unlike a Data Policy, a Business Rule can read old values, interact with other tables, create new records, update records, send email, and perform virtually any other server-side action. Business Rules are written in JavaScript using the GlideRecord API. They are the primary tool for server-side automation. There are four main types of Business Rules, and the exam expects you to know the difference:
Before Business Rule: A before business rule runs after the Data Policy has passed but before the current record is saved to the database. You use this to modify field values on the current record right before it is written. For example, you can automatically set a field called 'Closed Date' to the current date and time when a user changes the 'State' field to 'Closed'. This is efficient because you can change values without performing a separate database update.
After Business Rule: An after business rule runs after the record has been successfully saved to the database. You use this to perform actions that depend on the record being saved, such as creating a new record in a different table (e.g., creating a 'Task' when an 'Incident' is saved), sending a notification email, or updating a related record. The key restriction is that you cannot modify the current record you were acting on — it is already saved.
Async (Asynchronous) Business Rule: An async business rule also runs after the save, but it does not run immediately. Instead, the system queues the execution so it runs later. This is useful for actions that are not time-sensitive, such as generating a report or making a call to an external system. Using async rules improves performance for the user because they do not have to wait for the action to finish.
Display Business Rule: A display business rule runs when the form is loaded, before it is displayed to the user. This is a special type that runs on the server but affects what the user sees on the client. It is typically used to set field values or make fields read-only based on conditions when the form opens. It does not run when the record is saved.
The exam loves to test the execution order. The sequence is: Data Policy (before save) -> Before Business Rule -> Save to database -> After Business Rule (immediate or async). If a Data Policy fails, the Before Business Rule never runs. If a Before Business Rule runs and puts the data in a bad state that would fail the Data Policy, the save will still fail because the Data Policy check is the first gate. Understanding this chain is vital.
Data Policies are preferable when you need simple, code-free validation. Business Rules are required when you need more complex logic, such as looping through related records, making calculations, or creating new records. A common mistake beginners make is writing a Business Rule when a Data Policy would have been simpler and faster, or using a Data Policy thinking it can update other tables (it cannot). Always start by asking: "Do I just need to make a field mandatory or read-only based on state?" If yes, use a Data Policy. "Do I need to create a new record, send an email, or calculate a complex value?" Use a Business Rule.
Identify the Business Requirement
Before writing any code or configuring a rule, you must understand exactly what the stakeholder wants. Is the goal to prevent bad data from being saved (Data Policy)? Or is the goal to automate something after a record is saved (Business Rule)? Read the requirement carefully. For example, 'Make the Priority field mandatory when the Category is 'Network' is a Data Policy requirement. 'When the Priority is 1, create a critical incident alert' is a Business Rule requirement.
Navigate to the Correct Module
In ServiceNow, you configure Data Policies and Business Rules from different modules. For Data Policies, go to 'Data Policy' in the application navigator. For Business Rules, go to 'Business Rule'. Each module has a 'New' button. The exam expects you to know where to find these configuration pages. Do not confuse 'Data Policy' with 'Data Structure' or 'Data Export'.
Configure the Table and Conditions
Select the target table (e.g., 'Incident'). For a Data Policy, you set conditions using the graphical condition builder. For example: 'State is one of In Progress, On Hold'. For a Business Rule, you set the 'When to run' options: Insert (on create), Update (on any field change), Delete (on deletion), or Query (for display rules). The exam loves to test that a Before Business Rule set to 'Insert' will not run on an update.
Define the Action (Data Policy) or Script (Business Rule)
For a Data Policy, you check the boxes for Mandatory, Read-only, or Visible for each field. No scripting is needed unless you check 'Advanced' for a scripted condition. For a Business Rule, you write JavaScript inside the 'Script' field. The script uses the 'current' object to access the current record's fields. For example: current.callback = ''; sets the callback field to empty before save. For an After Business Rule, you might use var gr = new GlideRecord('task'); gr.initialize(); gr.setValue('short_description', 'Alert generated'); gr.insert(); to create a new record.
Test the Rule and Check the Execution Order
After saving the rule, navigate to a record on the target table and perform the action that triggers the rule. Open the 'System Log' to check if your script ran without errors. Verify that the Data Policy blocks a save when a mandatory field is empty. Verify that the Before Business Rule changes the field value before it is saved. This step is critical because the exam assumes you understand that a malfunctioning script can break the entire save process.
Set the Order and Move to Production
If you have multiple Business Rules on the same table, set the 'Order' field to ensure they run in the correct sequence. A rule with Order 10 runs before a rule with Order 100. Move the configuration from a development instance to a test instance, then to production. The exam does not test deployment steps, but in real life, this is how it works.
An IT department uses ServiceNow to manage employee onboarding. When a new manager is hired, the HR team creates an 'Employee Profile' record. The company has a strict policy: every new employee record must have a valid work email address before it can be saved. The IT team creates a Data Policy on the 'Employee Profile' table. The policy says: "If the field 'Email' is empty, show an error message and prevent the save." This ensures no employee record is ever created without a critical piece of data. That is a Data Policy doing its job — data integrity enforced at the gate.
Now, once that employee record is successfully saved, the company wants automatic things to happen. The IT team writes an After Business Rule on the 'Employee Profile' table. This rule is triggered after the record is saved. The rule does the following:
It creates a new record in the 'User Account' table, automatically generating a username and a temporary password.
It creates a new record in the 'Hardware Request' table to order a laptop.
It sends a welcome email to the new employee's personal email address.
These actions are complex and involve multiple tables. A Data Policy could never do this because Data Policies cannot create new records or send emails. A Business Rule is required. This is server-side automation in action.
Now consider a different scenario: a help desk ticket system. The company wants tickets in the 'Resolved' state to require a mandatory 'Resolution Notes' field. The solution is a Data Policy. No scripting is needed. The IT pro opens the 'Data Policy' module, selects the 'Incident' table, sets the condition: "When State is 'Resolved'" and the action: "Mandatory: Resolution Notes". Done. If the user tries to resolve an incident without typing notes, the save fails with an error message.
Later, the company realises that when a ticket is resolved, the system should automatically change the 'Assignment Group' to 'Service Desk Closed' and update the 'Resolved By' field with the current user's name. This is a Before Business Rule that runs on the 'Incident' table. The IT pro writes a short script that sets the assignment group field and the resolved-by field right before the record is saved. No email is sent, no new record is created — just a few field updates on the current record. A Before Business Rule is the most efficient choice here.
Finally, when a critical ticket (Priority 1) is created, the company needs to send an SMS alert to the on-call manager immediately. This requires an After Business Rule that checks if the priority is 1 and then calls an external API to send the SMS. This rule runs after the ticket is saved. The user sees the ticket saved first, and then the SMS is sent. If the rule fails, the ticket is still saved, but the manager might not get the alert.
The SNOW-CAD exam devotes a significant number of questions to this topic, usually 5-8 questions across the exam. The questions are designed to test two things: your knowledge of the execution order and your ability to pick the correct tool for the job. The traps are not about obscure script syntax; they are about conceptual understanding.
Execution order questions: The exam will give you a scenario with a Data Policy, a Before Business Rule, and an After Business Rule all on the same table. They will ask you what happens when the user saves the record. The trap is that many candidates think a Before Business Rule runs before a Data Policy. The correct order is Data Policy -> Before -> Save -> After. Memorise this sequence.
Tool selection questions: The exam will describe a business requirement and ask you to choose between a Data Policy, a Before Business Rule, an After Business Rule, or an Async Business Rule. The trap is choosing an After Business Rule when the requirement is to modify a field on the current record (which requires a Before Business Rule). Another trap is choosing a Data Policy when the requirement involves creating a record in a different table (which requires a Business Rule).
Order of execution within Business Rules: If multiple Before Business Rules exist on the same table, the exam may ask about the order they run. The order is determined by the 'Order' field on the Business Rule form (the lower the number, the higher the priority). They do not run alphabetically or in creation order.
Condition fields: The exam tests the difference between the 'When to run' conditions. A Business Rule can be configured to run on insert, update, delete, or query. A Data Policy can be configured on insert, update, or delete. The exam will ask which of these operations a Data Policy does NOT support (it does not support query). Similarly, a Display Business Rule only runs on query (when the form loads).
Scope and access: Business Rules run with full system rights by default. If you need to restrict what a Business Rule can access, you must use the 'Application' scope or use the 'Run with roles' option. Data Policies do not have this concept; they are always enforced.
The 'Advanced' flag: For both Data Policies and Business Rules, the exam loves the 'Advanced' checkbox. If the checkbox is unchecked, the system shows a simple graphical condition builder. If it is checked, you can write a script. Many beginners forget to check this box and wonder why their script is not running. The exam will show a screenshot of a Business Rule form with the 'Advanced' checkbox unchecked and ask what is missing.
Data Policy vs. ACL: Data Policies control field-level mandatory, read-only, and visibility settings. Access Control Lists (ACLs) control who can read, write, create, or delete records. The exam will present a scenario where a user cannot edit a field and ask what the cause is. If the error message is a 'Mandatory field' error, it is a Data Policy. If the error says 'User does not have permission', it is an ACL. Do not confuse them.
Data Policies run before the database save and can only validate data by making fields mandatory, read-only, or visible; they cannot change field values.
Business Rules run on the server and can read, write, create, update, and delete records across the entire ServiceNow instance.
The correct execution order is Data Policy check first, then Before Business Rule, then the database save, then After Business Rule.
Use a Before Business Rule only when you need to modify field values on the current record before it is saved to the database.
Use an After Business Rule when you need to create a related record, send an email, or perform any action that depends on the record being fully saved.
Display Business Rules run only when the form is loaded onto the screen, not during save operations, and are used for conditional field configurations.
When multiple Business Rules exist on the same table, their execution order is determined by the 'Order' field value, with the lowest number running first.
Data Policies cannot create records in other tables, send notifications, or execute complex logic; those tasks always require a Business Rule.
These come up on the exam all the time. Here's how to tell them apart.
Data Policy
No code required; configured via graphical interface
Cannot create or update records on other tables
Only checks field-level mandatory, read-only, and visibility
Business Rule
Requires JavaScript scripting using GlideRecord API
Can create, update, delete, and query records across tables
Can perform complex logic like loops, conditionals, and API calls
Before Business Rule
Runs before the record is saved to the database
Can modify the current record's field values
Cannot create records in other tables (though it can read them)
After Business Rule
Runs after the record is committed to the database
Cannot modify the current record's field values
Ideal for creating related records, sending notifications, or performing external actions
Data Policy
Runs on the server before the database save
Enforces data integrity regardless of form layout
Applies to all data submissions (API, import sets, etc.)
UI Policy
Runs on the client side (user's browser) after form load
Only affects fields visible on the form; does not affect API submissions
Primarily used for making fields visible, hidden, or read-only for user experience
Before Business Rule
Runs on insert, update, or delete events
Executes before the database save
Used to automatically set field values or run calculations
Display Business Rule
Runs only on query events (when the form is loaded)
Executes after the record is fetched from the database but before the form is displayed
Used to dynamically set field attributes (read-only, default values) based on conditions when the form opens
Async Business Rule
Triggered automatically by a specific record event (insert, update)
Queued to run asynchronously, but typically runs within seconds
Best for tasks that need to be associated with a specific record change
Scheduled Job
Runs on a predetermined schedule (every hour, daily, etc.)
Not tied to any single record event; runs independently
Best for batch processes, data cleanups, or reports that run at a fixed interval
Mistake
A Data Policy can update fields on the current record when conditions are met, just like a Before Business Rule.
Correct
A Data Policy only validates data; it cannot modify, set, or change any field values. It only makes fields mandatory, read-only, or visible/invisible. If you need to set a field value automatically, you must use a Before Business Rule.
The ServiceNow interface for Data Policies has a 'Mandatory' and 'Read-only' section that looks similar to a form configuration. Beginners see the 'Mandatory' checkbox and think it can also 'set' a value, but it only blocks or allows input; it never writes data.
Mistake
An After Business Rule runs immediately after the save, so it can modify the record that was just saved and save it again.
Correct
An After Business Rule runs after the record is committed to the database. It cannot modify the current record using the 'current' variable because that record is already saved. If you try to call current.update() within an After Business Rule, it will create an infinite loop or cause an error. You can only update related records or create new ones.
The word 'After' is misleading. Learners assume 'after save' means 'the record is still open for editing', but the database transaction is complete. This confusion leads to infinite loops or failed exam answers.
Mistake
Display Business Rules run every time a record is updated or saved.
Correct
Display Business Rules only run when the form is loaded onto the screen (a query operation). They do not run on insert, update, or delete. They are used to configure the form before the user sees it, not during data submission.
The name 'Display' suggests it is about showing data, which is correct, but beginners assume that because it is a type of Business Rule, it runs on all operations. The distinct event type (query) is an easy detail to forget.
Mistake
You can have as many Data Policies on a table as you want, and they all run in the order you created them.
Correct
Data Policies run in a specific order based on their 'Order' field, but if multiple Data Policies conflict (one says a field is mandatory, another says it is read-only), the system applies the most restrictive rule. The order does not matter for conflict resolution — the restrictive rule wins.
Learners are familiar with Business Rules having an order, so they assume Data Policies behave identically. But Data Policies use a 'restriction stacking' logic, not a sequential execution logic. This is not documented in the beginner guides, so it surprises candidates.
Mistake
Data Policies can only be applied to fields that are on the form layout.
Correct
Data Policies apply to the underlying table, not the form. Even if a field is not visible on the form, a Data Policy can still make it mandatory or read-only. The record save will fail if the hidden mandatory field has no value, even if the user cannot see it.
ServiceNow's form layout editor (UI Policy) is client-side and only affects what is shown. Beginners confuse Data Policies (server-side) with UI Policies (client-side) and assume Data Policies only check visible fields.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Data Policy is a code-free rule that validates field data before it is saved, only making fields mandatory, read-only, or visible. A Business Rule is a JavaScript script that can perform any server-side action (create records, send emails, update other tables) and runs either before or after the save.
Use a Before Business Rule. Data Policies cannot set or change field values; they only validate. A Before Business Rule can modify the current record's fields before the save completes.
A Data Policy runs before a Before Business Rule. The order is: Data Policy -> Before Business Rule -> Database Save -> After Business Rule. If the Data Policy fails, the Before Business Rule never runs.
Yes. Data Policies apply at the database table level, not the form level. Even if a field is not visible on the form, a Data Policy can make it mandatory. The save will fail if the hidden field has no value.
The system applies the most restrictive rule. If one Data Policy forces a field to be mandatory and another forces it to be read-only, the read-only restriction wins because it restricts the user from modifying the field.
Check that the 'When to run' conditions are correct (Insert, Update, Delete, Query). Ensure the 'Advanced' checkbox is checked if you are using a script. Verify that the table name is correct and that the condition builder is not filtering out all records. Also check that the rule is 'Active' (the Active checkbox is ticked).
No. Data Policies cannot send emails, create records, or perform any action beyond field validation. You must use an After Business Rule or a Flow (Flow Designer) for sending emails or creating records.
You've finished Business Rules and Data Policies. Continue through the SNOW-CAD study guide to build a complete picture of the exam.
Done with this chapter?