CSA Guide

Data Policies and Field Enforcement

Introduction

One of the most common gaps in ServiceNow configurations is mandatory field enforcement that works on a form but fails when records are created via API, import sets, or integration. The root cause is almost always relying on UI Policies instead of Data Policies for critical fields.

This guide clarifies the difference and shows you when to use each.

The Core Distinction

Feature	UI Policy	Data Policy
Enforces mandatory	Browser form only	ALL channels
Enforces read-only	Browser form only	ALL channels
Evaluated	Client-side (browser)	Server-side (database write)
Bypassed by API	✅ Yes	❌ No
Bypassed by Import Sets	✅ Yes	❌ No
Bypassed by Business Rules	✅ Yes	❌ No
Applies to	Specific form view	Table-level

Bottom line: If a field is truly required for business logic to function, use a Data Policy. UI Policies are for user experience, not enforcement.

Creating a Data Policy

System Policy > Data Policies > New

Configuration

Table: The table to enforce on (e.g., incident)
Conditions: When the policy applies (e.g., State = Resolved)
Apply to import sets: Check this to enforce during Import Set transforms
Apply to SOAP: Check to enforce for SOAP API calls

Data Policy Rules

Under the Data Policy Rules related list, add field enforcement:

Field	Mandatory	Read Only
`close_code`	true	false
`close_notes`	true	false
`resolved_at`	true	false

Practical Example: Requiring Resolution Fields

A common requirement: when an incident is resolved, the close_code and close_notes fields must be populated.

Wrong approach: UI Policy with condition State = Resolved making these fields mandatory. An API call that sets state=Resolved without these fields will succeed silently.

Right approach:

Data Policy:

Table: incident
Conditions: State = Resolved
Rules: close_code mandatory, close_notes mandatory

Now any attempt to resolve an incident — via form, REST API, import, or script — without these fields will be rejected with an error.

Data Policies vs. Business Rules for Validation

You can also enforce mandatory fields in a before Business Rule using current.setAbortAction(true). When should you use each?

Use Data Policy when:

The requirement is purely "field must not be empty"
You want a declarative, no-code solution
Non-developers need to maintain the rule

Use Business Rule when:

The validation logic is complex (cross-field checks, lookups)
You need a custom error message via gs.addErrorMessage()
The condition requires computed logic

UI to Data Policy: The Conversion Pattern

If you already have UI Policies for critical fields, convert them:

Identify UI Policies that enforce mandatory on important tables
Check if those fields could be set via API or integration
If yes — create an equivalent Data Policy
Keep the UI Policy for the user experience (immediate visual feedback)
The Data Policy is the safety net

The two can coexist. UI Policy provides real-time form feedback; Data Policy catches anything that bypasses the form.

Viewing Policy Conflicts

If a UI Policy and a Data Policy conflict (one says read-only, one says editable), the Data Policy wins for server-side enforcement. The browser still shows the UI Policy's behavior.

Best Practices

Audit existing UI Policies that enforce mandatory on high-volume tables
Convert critical field requirements to Data Policies
Always enable "Apply to import sets" for fields that come in via data migration
Use Business Rules for complex cross-field validation
Document the reason for each Data Policy in its Description field
Test Data Policy enforcement via a background script, not just the form

Conclusion

Data Policies close the gap between what your form enforces and what your data actually contains. Every time a critical field is only enforced via a UI Policy, you have a vulnerability — an API call, an import, or a background script can produce invalid records. Identify those fields, create Data Policies, and sleep better knowing your data integrity holds regardless of how records are touched.