Data Policies

Data Policies in ServiceNow – Complete Guide for CAD Exam

Introduction to Data Policies

Data Policies are a critical concept in ServiceNow that every Certified Application Developer (CAD) candidate must thoroughly understand. They play a vital role in ensuring data integrity across the platform by enforcing rules on how data is entered and stored, regardless of how or where the data originates.

Why Are Data Policies Important?

In any enterprise application, maintaining clean and consistent data is essential. Without proper enforcement mechanisms, users or integrations could submit incomplete or invalid records, leading to downstream issues in reporting, automation, and business processes. Data Policies address this need by:

• Ensuring data consistency – They enforce mandatory fields and validation rules across all access points, not just the standard form interface.
• Extending beyond the UI – Unlike UI Policies, which only apply when a user interacts with a form in the browser, Data Policies can enforce rules on data entered via web services, import sets, and other server-side operations.
• Reducing errors and rework – By catching invalid or missing data at the point of entry, Data Policies prevent bad data from entering the system.
• Supporting compliance – Organizations often have regulatory or internal compliance requirements that mandate certain fields be populated. Data Policies help enforce these requirements universally.

What Are Data Policies?

A Data Policy in ServiceNow is a server-side rule that enforces data requirements on a specific table. Data Policies can make fields mandatory or read-only based on defined conditions. They function similarly to UI Policies but with a key distinction: Data Policies are enforced on the server side, meaning they apply to data coming from any source — forms, web services, import sets, list edits, and more.

Key characteristics of Data Policies:

• They are defined on a specific table.
• They use conditions to determine when the policy should be applied.
• They specify actions — making fields mandatory or read-only.
• They can be configured to apply on the UI, on server-side processing, or both.
• They do NOT support scripting — unlike UI Policies, Data Policies are purely declarative (no scripts).
• They do NOT support showing/hiding fields — they can only enforce mandatory and read-only states.

Data Policies vs. UI Policies – Key Differences

Understanding the difference between Data Policies and UI Policies is one of the most commonly tested concepts on the CAD exam:

UI Policies:
• Client-side enforcement only (browser)
• Can make fields mandatory, read-only, or visible/hidden
• Support scripting (onLoad and onChange scripts)
• Only apply when users interact with the form
• Do NOT enforce rules on data submitted via APIs, import sets, or other non-UI channels

Data Policies:
• Server-side enforcement (and optionally client-side)
• Can make fields mandatory or read-only only (NO show/hide capability)
• Do NOT support scripting
• Apply to data from ALL sources when configured for server-side enforcement
• Can also apply to the UI if the "Apply to import sets" or "Use as UI Policy on client" options are enabled

How Do Data Policies Work?

Here is a step-by-step breakdown of how Data Policies function:

1. Creating a Data Policy:
• Navigate to System Policy > Data Policies.
• Click New to create a new Data Policy.
• Select the Table the policy applies to (e.g., Incident, Change Request).
• Define the Conditions under which the policy should be enforced. For example: "When Priority is 1 - Critical."

2. Configuring Enforcement Options:
• Apply to import sets – When checked, the policy is enforced on data coming through import sets and web services (server-side enforcement).
• Use as UI Policy on client – When checked, the Data Policy also behaves like a UI Policy and enforces rules on the form in the browser. This creates a corresponding UI Policy automatically.
• Reverse if false – When checked, if the condition evaluates to false, the actions are reversed (e.g., a field that was made mandatory becomes non-mandatory).
• Inherit – When checked, the policy applies to tables that extend the specified table.

3. Defining Data Policy Rules (Actions):
• In the Data Policy Rules related list, you specify which fields are affected and what action to take.
• For each field, you can set it to Mandatory (Yes/No) and/or Read-only (Yes/No).

4. Execution Flow:
• When a record is inserted or updated, ServiceNow evaluates all active Data Policies for the relevant table.
• If the record matches the Data Policy's conditions, the defined rules are enforced.
• If a mandatory field is empty, the operation is rejected and an error message is returned.
• If the "Use as UI Policy on client" option is enabled, the browser also enforces the rules in real-time on the form.

Practical Example

Suppose your organization requires that the Close Notes field must be filled in whenever an Incident is moved to a Resolved state. Here's how you would configure this:

• Table: Incident [incident]
• Condition: State is Resolved
• Apply to import sets: Checked (so it's enforced even when incidents are resolved via integrations)
• Use as UI Policy on client: Checked (so users on the form also see the field marked as mandatory)
• Reverse if false: Checked (so Close Notes is not mandatory when the state is not Resolved)
• Data Policy Rule: Close Notes → Mandatory = Yes

With this configuration, no matter how a record is updated — via the form, REST API, import set, or any other method — the Close Notes field will be required when the Incident is in a Resolved state.

Key Properties and System Behavior

• Data Policies are evaluated after Business Rules that run "before" the database operation.
• If both a UI Policy and a Data Policy conflict, the Data Policy takes precedence on the server side.
• The system property glide.data_policy.enforce can be used to globally enable or disable server-side Data Policy enforcement.
• Data Policies do not fire on delete operations — only on insert and update.

Common Use Cases

• Enforcing mandatory fields during state transitions (e.g., requiring resolution notes when closing an incident)
• Ensuring data quality from integrations and import sets
• Making certain fields read-only after a record reaches a specific state (e.g., preventing changes to Priority after approval)
• Applying consistent data rules across multiple input channels without writing scripts

Exam Tips: Answering Questions on Data Policies

The CAD exam frequently tests your understanding of Data Policies. Here are specific tips to help you answer these questions correctly:

Tip 1: Remember the Core Difference from UI Policies
If a question asks about enforcing data rules on records submitted via web services, import sets, or integrations, the answer is almost always Data Policy, not UI Policy. UI Policies only work on the client (browser).

Tip 2: Data Policies Cannot Show/Hide Fields
If a question mentions making a field visible or hidden, Data Policy is NOT the correct answer. Only UI Policies can control field visibility. Data Policies are limited to mandatory and read-only.

Tip 3: Data Policies Do NOT Support Scripts
If a question involves running a script or executing custom logic, Data Policy is not the right choice. Data Policies are purely declarative — no scripting capability.

Tip 4: Know the "Use as UI Policy on client" Checkbox
Questions may describe a scenario where a rule needs to apply both on the form and on server-side operations. The answer is a Data Policy with the "Use as UI Policy on client" option checked. This gives you the best of both worlds.

Tip 5: Know the "Apply to import sets" Checkbox
If the question specifically mentions enforcing rules during data imports, remember that the "Apply to import sets" checkbox must be enabled for the Data Policy to take effect on import sets.

Tip 6: Reverse if False
Understand that checking "Reverse if false" means the policy's actions are undone when the condition is no longer met. This is similar to the reverse functionality in UI Policies.

Tip 7: Watch for Trick Questions About Precedence
If a question asks what happens when a UI Policy and a Data Policy conflict, remember that the server-side Data Policy ultimately wins because it is enforced at the server level, even if the UI Policy allows the action on the client.

Tip 8: Inheritance
Data Policies can be configured to apply to extended tables through the Inherit option. If a question mentions a parent table like Task and asks if the policy can also apply to Incident or Change Request (which extend Task), the answer is yes — if inheritance is enabled.

Tip 9: Elimination Strategy
When facing a multiple-choice question, quickly eliminate options that involve client-side-only solutions (UI Policies, Client Scripts) if the scenario requires server-side enforcement. This narrows your choices significantly.

Tip 10: Scenario-Based Questions
Many CAD exam questions present a real-world scenario. Pay close attention to phrases like:
• "...must be enforced regardless of how the data is entered" → Data Policy
• "...should apply when the user is on the form" → Could be UI Policy or Data Policy with UI enforcement
• "...needs to hide a field" → UI Policy (NOT Data Policy)
• "...needs to run a script when a value changes" → UI Policy or Client Script (NOT Data Policy)

Summary

Data Policies are a powerful, declarative mechanism in ServiceNow for enforcing data quality rules at the server level. They complement UI Policies by extending enforcement beyond the browser to all data input channels, including web services and import sets. For the CAD exam, focus on understanding what Data Policies can and cannot do, how they differ from UI Policies, and when to use each. Remember: Data Policies handle mandatory and read-only enforcement on the server side, with no scripting and no show/hide capability. Mastering these distinctions will help you confidently answer Data Policy questions on the exam.