# Business Rules and Data Policies

> Chapter 7 of the Courseiva SERVICENOW-CAD curriculum — https://courseiva.com/learn/servicenow-cad/business-rules-and-data-policies

**Official objective:** 3.2 — Apply business rules and data policies for server-side automation and data integrity

## Introduction

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.

## The Apartment Building Rule Book Analogy

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.

## Core explanation

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.

## Real-world context

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.

## Exam focus

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.

## Step by step

1. **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.
2. **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'.
3. **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.
4. **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.
5. **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.
6. **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.

## Comparisons

### Data Policy vs Business Rule

**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 vs After Business Rule

**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 vs UI Policy

**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 vs Display Business Rule

**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 vs Scheduled Job

**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

## Diagram

_Execution order of Data Policies and Business Rules when a user saves a record in ServiceNow._

```mermaid
flowchart TD
    A[User Saves Record] --> B{Data Policy Passes?}
    B -- Yes --> C[Before Business Rule runs]
    B -- No --> D[Save Blocked
Error Message Shown]
    C --> E[Record Saved to Database]
    E --> F[After Business Rule runs]
    F --> G[Async Business Rule runs
(scheduled later)]
    E --> H[Display Business Rule
(on form load only)]
```

## Common misconceptions

- **Misconception:** A Data Policy can update fields on the current record when conditions are met, just like a Before Business Rule. **Reality:** 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.)
- **Misconception:** An After Business Rule runs immediately after the save, so it can modify the record that was just saved and save it again. **Reality:** 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.)
- **Misconception:** Display Business Rules run every time a record is updated or saved. **Reality:** 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.)
- **Misconception:** You can have as many Data Policies on a table as you want, and they all run in the order you created them. **Reality:** 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.)
- **Misconception:** Data Policies can only be applied to fields that are on the form layout. **Reality:** 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.)

## Key takeaways

- 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.

## FAQ

**What is the difference between a Data Policy and a Business Rule?**

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.

**If I want to set a field value automatically when a record is saved, should I use a Data Policy or a Business Rule?**

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.

**Does a Data Policy run before or after a Before Business Rule?**

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.

**Can a Data Policy make a field mandatory that is hidden from the form?**

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.

**What happens if two Data Policies conflict on the same field (one says mandatory, the other says read-only)?**

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.

**Why is my Business Rule script not running?**

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).

**Can a Data Policy send an email when a field is updated?**

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.

## Check your understanding

1. **When a user saves a record, what component runs first: the Data Policy or the Before Business Rule?**

   Answer: The Data Policy runs first. If it fails, the Before Business Rule never runs.

2. **You need to automatically set the 'Closed Date' field to the current date and time when an incident state changes to 'Closed'. Should you use a Data Policy or a Before Business Rule?**

   Answer: Use a Before Business Rule because it can modify the current record's field values before the save. A Data Policy cannot set values.

3. **A company wants that when a new employee record is created, a welcome email is sent. Which Business Rule type is the correct choice?**

   Answer: Use an After Business Rule because it runs after the record is committed to the database, which is necessary because the email action depends on the record existing.

4. **What is the difference between the 'Advanced' checkbox on a Data Policy versus a Business Rule?**

   Answer: For both, checking the 'Advanced' box allows you to write a script instead of using the graphical condition builder. However, for a Data Policy, the script can only define conditions; the actual validation (mandatory/read-only) is still set via the GUI. For a Business Rule, the entire logic (conditions and actions) is written in the script.

5. **If you have two Before Business Rules on the same table, one with Order 10 and one with Order 20, which one runs first?**

   Answer: The Business Rule with Order 10 runs first because the system executes rules in ascending order of the Order field value.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-cad/business-rules-and-data-policies