⬡ Part 6 · Topic 1

Data Policies & Dictionary Overrides

Data Policies enforce field rules at the server level — making fields mandatory or read-only everywhere, including APIs and imports. Understand the critical difference from UI Policies, and when Dictionary Overrides let you customize rules per child table.

📋 5 sections ⏱ ~20 min read 🎯 ~10% exam weight 🏷 Data Quality

🔗

Builds On — Part 1 Topics 1 & 2 Both mechanisms in this topic operate on the data dictionary you studied in Part 1 Topic 2 (Field Types & Dictionary): a Data Policy makes a dictionary field mandatory or read-only at runtime, and a Dictionary Override customizes a field's dictionary entry for a specific child table. You also need Part 1 Topic 1 (table inheritance) to understand why Data Policies say "applies to all child tables" — because in ServiceNow, child tables inherit their parent's fields via single-table inheritance, so a policy on task propagates to incident, sc_req_item, and every other task child.

Section 1

The Data Quality Problem

Data quality degrades when there are no rules enforcing what values are required, which fields should be restricted, and what format data should follow. Without enforcement, users skip important fields, enter inconsistent values, or import bad data through APIs that bypass form-level validations.

ServiceNow has several layers of data quality control. Understanding which layer enforces rules at what level is crucial — the exam frequently tests the enforcement scope of each mechanism.

Section 2

Data Policies — Server-Side Enforcement

A Data Policy is a server-side rule that makes a field mandatory or read-only. The critical word is server-side — it runs on the server and applies regardless of how data is submitted. Whether a user saves a form, an API call sends a PATCH request, an import set transform writes a record, or a script runs a GlideRecord insert — the Data Policy enforces its rules every time.

Data Policies are configured at System Policy → Data Policies. Each policy specifies:

Table — which table the policy applies to (including all child tables)
Conditions — an encoded query; the policy only activates when these conditions are true
Field Rules — per-field rules: Mandatory, Read-only, or both

📘

Core Concept — Data Policies Apply Everywhere Data Policies are enforced server-side: the database layer, not the form layer. This means they apply to UI saves, API calls, Transform Map imports, and even scripted GlideRecord inserts. A missing mandatory field causes a save failure with a validation error regardless of how the data was submitted.

Conditional Data Policies

Data Policies can be conditional — they only apply when a record meets certain criteria. For example: "make Category mandatory only when Impact = 1 (High)." The condition is an encoded query on the current record. When the condition is true, the field rules apply. When false, the fields are optional.

Section 3

UI Policies — Client-Side Only

A UI Policy also makes fields mandatory or read-only, but it runs only in the browser — client-side. It only affects users who are using the standard ServiceNow form interface. UI Policies are bypassed by API calls, Import Sets, and background scripts entirely.

UI Policies are configured at System UI → UI Policies. They support the same conditional logic as Data Policies — "make field X mandatory when field Y = value Z" — but this logic runs in JavaScript in the user's browser.

⚠

Exam Trap — UI Policy vs. Data Policy Enforcement Scope This is one of the highest-frequency exam questions. UI Policies only affect form users. Data Policies enforce at the database layer and apply everywhere.

Scenario: "An API integration is inserting records without filling in the Category field, but Category is set as mandatory in a UI Policy. Why is the API succeeding?" Answer: UI Policies don't affect APIs. To block the API as well, convert to a Data Policy.

Side-by-Side Comparison

Aspect	UI Policy	Data Policy
Enforcement level	Client-side (browser only)	Server-side (database layer)
Applies to API calls	No	Yes
Applies to imports	No	Yes
Applies to scripts	No	Yes
Real-time response	Immediate — field grays out as you type	At save time — error returned on save
Can hide/show fields	Yes — UI Policies can show/hide fields	No — only mandatory/read-only
Configuration location	System UI → UI Policies	System Policy → Data Policies

Section 4

Dictionary Overrides — Per-Table Field Behavior

We introduced Dictionary Overrides in Part 1 Topic 2. In the context of data quality, they are a powerful tool for making fields mandatory on a specific child table without affecting the parent or other siblings.

For example: the task table has a category field. By default, it's optional on all task subtypes. You want to make it mandatory on incident only. Options:

Dictionary Override on incident — sets mandatory=true on the field for the incident table only. All other task subtypes are unaffected.
Data Policy with condition sys_class_name=incident — achieves the same effect but is more discoverable as a named policy.
Editing the parent field directly — WRONG. This makes the field mandatory on ALL task subtypes, not just incidents.

💡

Tip — Dictionary Override vs. Data Policy for Mandatory Fields Both achieve mandatory on a child table. Dictionary Overrides are set directly in the dictionary and are good for permanent structural changes. Data Policies are named, discoverable records that can be conditionally active and are easier to audit. For CIS-DF exam purposes: if the question says "enforce mandatory on the child table without affecting the parent," both are valid approaches — the distinction is in how they are managed and their enforcement scope.

Section 5

Business Rules for Validation

For validations more complex than mandatory/read-only — like "if field A = X, then field B must be in set {1, 2, 3}" — you use a Business Rule with condition type before (fires before insert/update, can abort the save).

In the Business Rule script, use current.setAbortAction(true) to abort the save, and gs.addErrorMessage('message') to display the error message to the user.

// Before Insert/Update — validate urgency matches impact
if (current.impact == 1 && current.urgency == 3) {
current.setAbortAction(true);
gs.addErrorMessage('High impact incidents cannot have low urgency.');
}

⚠

Exam Trap — Business Rule Timing Only Business Rules with timing Before (before insert/update) can abort a save. Rules with timing After fire after the record is already committed — you cannot abort at that point. For data validation, always use "Before" timing.

Exam Quick Reference

Common Exam Traps — Data Policies & Dictionary Overrides

Data Policies = server-side, apply everywhere (UI, API, imports, scripts)
UI Policies = client-side only, bypassed by API calls and imports
If an API is bypassing mandatory field enforcement, the solution is a Data Policy, not a UI Policy
Dictionary Overrides allow per-child-table field behavior changes without modifying the parent
Modifying the parent field affects ALL child tables — use Override or conditional Data Policy for child-only changes
Business Rule with Before timing + setAbortAction(true) = custom field validation that blocks saves

Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Data Policies & Dictionary Overrides Quiz 1 / 4

A UI Policy makes the "category" field mandatory on the Incident form. A REST API integration creates incidents without a category and succeeds. What is the problem?

💡 Explanation

B is correct. UI Policies run in the browser (client-side JavaScript) and only enforce rules when a user submits a form through the UI. They have zero effect on REST API calls, import sets, scripts, or any server-side operation. Data Policies, by contrast, are enforced server-side and apply to ALL write operations regardless of source — UI, API, import, or script. To enforce mandatory fields for API integrations, you need a Data Policy.

Next: Field Validation & Choice Lists →