Data Policy

What It Is

Data Policy is ServiceNow's server-side field validation engine that enforces business rules at the database layer, making fields mandatory or read-only regardless of how data enters the system. While UI Policies only apply to browser-based form interactions, Data Policies execute during every record operation — form submissions, REST API calls, web service requests, import operations, and bulk updates. This makes Data Policies the definitive enforcement mechanism for critical field validation that cannot be circumvented by technical users or external integrations. The policy engine evaluates conditions against record data and applies field restrictions before the record commits to the database, ensuring data integrity across all entry points.

Architecturally, Data Policies live in the System Policy application under System Definition > Data Policies and execute within ServiceNow's server-side processing pipeline alongside Business Rules and Access Controls. Each Data Policy record (sys_data_policy table) contains condition logic that determines when the policy applies, while related Data Policy Rules (sys_data_policy_rule table) define the specific field restrictions to enforce. The policy engine integrates with ServiceNow's form processing layer and database abstraction layer, intercepting record operations before they reach the underlying MySQL database.

The underlying data model treats Data Policies as conditional rule sets that map to specific tables through the Table field on each policy record. When a record operation occurs, ServiceNow's policy engine queries active Data Policies for the target table, evaluates their conditions against the current record state, and applies matching policy rules before processing continues. This execution happens during the server-side form processing phase, after client-side validation but before Business Rules fire. The policy engine caches compiled condition scripts and rule definitions for performance, but re-evaluates conditions on every record operation to ensure current data drives policy decisions.

You cannot function without Data Policies when external integrations, API consumers, or bulk operations need the same field validation as interactive users. Critical scenarios include enforcing approval workflows where State changes require specific supporting fields, preventing API users from bypassing mandatory change documentation, or ensuring imported records meet the same data quality standards as manually created ones. Financial applications particularly depend on Data Policies to prevent cost centers, accounting codes, or approval fields from being omitted during automated processes. Without Data Policies, any script, integration, or import can create incomplete records that violate business rules, creating data integrity issues that UI Policies cannot prevent.

ServiceNow administrators typically create and manage Data Policies as part of application configuration, though developers working on scoped applications control policies within their application scope. Platform owners and system administrators manage global policies that apply across multiple applications, while application developers focus on policies specific to their custom tables and business logic. The responsibility model mirrors Business Rules — administrators handle standard platform policies while developers manage custom application logic. Most organizations establish Data Policy governance where administrators review all policies for performance impact and business alignment before activation.

Recent ServiceNow releases have improved Data Policy performance through better condition caching and reduced the overhead of policy evaluation during bulk operations. Vancouver introduced enhanced debugging capabilities in System Diagnostics > Session Debug that shows Data Policy execution timing and condition evaluation results. Washington and Xanadu releases have strengthened the integration between Data Policies and Flow Designer, ensuring that record operations within flows properly respect Data Policy rules. The policy engine now provides more detailed error messages when policy violations occur, making it easier to identify which specific policy and rule caused a validation failure.

Where to Find and Configure It

Navigate to System Definition > Data Policies for the primary configuration interface where you create, modify, and manage all Data Policy records. From System Definition > Tables, select any table record and use the Data Policies related list to see policies specific to that table. Access System Definition > Data Policy Rules to directly manage the individual field rules that define what each policy enforces.

In Studio, open any application and navigate to Data Model > Data Policies to create policies scoped to your application, while App Engine Studio users find Data Policies under Logic and automation > Data policies in the app builder interface. For troubleshooting active policies, use System Diagnostics > Session Debug with Data Policy debugging enabled to see which policies execute during record operations. Check System Logs > All for Data Policy error messages when validation failures occur.

How It Works Step by Step

Data Policies execute within ServiceNow's server-side record processing pipeline, intercepting record operations after client-side validation completes but before Business Rules process the record. The policy engine maintains an internal cache of active policies organized by table, with condition scripts pre-compiled for performance. When any record operation occurs — form submission, API call, import, or script-based update — ServiceNow queries this cache for policies targeting the affected table and evaluates each policy's conditions against the current record state.

The policy evaluation process examines both the record's current field values and any changes being made during the operation, allowing conditions to reference previous values, new values, or derived information. When a policy's conditions evaluate to true, ServiceNow applies all associated Data Policy Rules for that policy, checking each affected field against the rule requirements. If any mandatory field lacks a value or any read-only field contains changes, the policy engine generates validation errors that halt the record operation and return specific error messages to the calling process.

The Execution Order

1. Record operation initiated (form submit, API call, import, script update)
2. Client-side validation completes (UI Policies, client scripts, mandatory field checks)
3. ServiceNow queries cached Data Policies for the target table and any parent tables in the hierarchy
4. Policy engine evaluates condition scripts for each active policy, passing current record data as context
5. For policies with true conditions, ServiceNow retrieves associated Data Policy Rules and validates each affected field
6. Any validation failures generate error messages and halt record processing, returning errors to the calling process
7. Successful validation allows processing to continue to Business Rules and database operations

// Common Data Policy condition script pattern
// Checks if incident is being resolved and requires resolution notes

// Access current record values
var currentState = current.incident_state;
var previousState = previous.incident_state;
var resolutionNotes = current.close_notes;

// Check if state is changing to resolved (6) or closed (7)
if ((currentState == '6' || currentState == '7') && 
    (previousState != '6' && previousState != '7')) {
    
    // Policy applies when transitioning to resolved/closed
    answer = true;
    
} else {
    // Policy does not apply for other state changes
    answer = false;
}

// The 'answer' variable determines if this policy's rules execute

Real-World Scenarios

Mandatory Change Documentation for API Updates

External applications frequently update Change Request records via REST API without providing required documentation fields that interactive users must complete. The business requires all production changes to include implementation plans and backout procedures regardless of how the change record gets updated.

// Data Policy Condition: Apply when change affects production
var environment = current.u_environment;
var changeType = current.type;

// Apply policy for production changes of any type
if (environment == 'production' && !gs.nil(changeType)) {
    answer = true;
} else {
    answer = false;
}

// Data Policy Rules to create:
// 1. Implementation Plan (u_implementation_plan) - Mandatory
// 2. Backout Plan (u_backout_plan) - Mandatory  
// 3. Risk Assessment (risk) - Mandatory

Create the Data Policy with Table = Change Request [change_request] and add three Data Policy Rules making the documentation fields mandatory. Watch for import operations that might fail validation — provide clear error messages in the Mandatory - message field so API consumers understand exactly what data they're missing. Consider adding exception handling for emergency changes that might need expedited processing.

Protecting Financial Fields from Unauthorized Modification

Once Purchase Orders reach approved status, accounting regulations require that cost centers and budget codes become read-only to prevent unauthorized financial adjustments. Scripts and integrations sometimes attempt to modify these fields after approval, creating audit compliance issues.

// Data Policy Condition: Lock financial fields when PO is approved
var currentState = current.state;
var approval = current.approval;

// Apply when PO is approved (state = approved) or approval = approved
if (currentState == 'approved' || approval == 'approved') {
    answer = true;
} else {
    answer = false;
}

// Data Policy Rules to create:
// 1. Cost Center (cost_center) - Read Only
// 2. Budget Code (u_budget_code) - Read Only
// 3. Department (department) - Read Only

Configure the policy against the Purchase Order table with read-only rules for all financial reference fields. Test thoroughly with Business Rules that might try to update these fields programmatically — the Data Policy will block those updates and could cause rule failures. Review any scheduled jobs or integrations that update PO records to ensure they don't modify protected fields after approval workflows complete.

Enforcing Assignment Rules Across All Data Entry Methods

Service desk tickets created through email, web forms, and API integrations sometimes bypass assignment logic that ensures proper routing. The business requires every incident to have both an Assignment Group and a specific assignee before reaching Active status.

// Data Policy Condition: Enforce assignment when incident becomes active
var currentState = current.incident_state;
var previousState = previous.incident_state;

// Apply when transitioning to Active (2) or any higher state
if (currentState >= 2 && (gs.nil(previous) || previousState < 2)) {
    answer = true;
} else {
    answer = false;
}

// Data Policy Rules to create:
// 1. Assignment Group (assignment_group) - Mandatory
// 2. Assigned To (assigned_to) - Mandatory
// Messages: "Active incidents require assignment group and assignee"

Create mandatory rules for both assignment fields with clear error messages that guide users toward proper assignment. Coordinate with existing Assignment Rules and Business Rules to ensure they populate these fields before the state transition occurs. Monitor email-to-incident processing and API integrations closely after implementing this policy — they may need modification to set assignment fields during initial record creation rather than in separate update operations.

The Classic Mistake

The most destructive mistake is creating a Data Policy on task table that makes assignment_group mandatory, not realizing it will apply to ALL task-extended tables. Admins create the policy thinking it only affects Incidents, then discover it's blocking Change Requests, Service Catalog items, Project Tasks, and every other table that extends task. Users suddenly cannot create any tasks across the platform without specifying an assignment group, even when the business process doesn't require it. The Data Policy Table field shows task [task] but the scope isn't obvious to most admins.

// Data Policy record on task table
Table: task [task]
Short description: Assignment Group Required
Active: true

// Data Policy Rule
Field name: assignment_group
Mandatory: true
Read only: false
Condition: [empty]

// This WILL enforce on:
// - incident, change_request, sc_request, kb_knowledge
// - pm_project_task, change_task, sc_task
// - problem, u_custom_task_table
// Result: Assignment group becomes mandatory on ALL these tables
// User cannot save ANY task record without selecting assignment group

This fails because ServiceNow applies Data Policies based on table inheritance, not just the specific table selected. When you create a policy on task, the system enforces it on every record where sys_class_name extends from task. Users see "Assignment group is mandatory" errors across dozens of forms they've used successfully for months. The mistake is non-obvious because the Data Policy interface doesn't clearly indicate inheritance scope, and most admins test only on the primary table they intended to target.

// Data Policy record on incident table specifically
Table: incident [incident]
Short description: Assignment Group Required for Incidents
Active: true

// Data Policy Rule
Field name: assignment_group
Mandatory: true
Read only: false
Condition: [empty]

// Alternative: Use conditions to limit scope even on parent tables
Table: task [task]
Condition: sys_class_name=incident^ORsys_class_name=problem

// This approach enforces only where intended
// Other task-extended tables remain unaffected

When to Use This vs Alternatives

Use Data Policies when you need server-side field validation that cannot be bypassed by REST API calls, imports, or direct database operations. This is your only option for true data integrity enforcement across all entry points into ServiceNow.

Choose Data Policies When

You need compliance-grade field enforcement that works regardless of how data enters the system. UI Policies only apply to browser forms, so integration users and imports can bypass them entirely. Data Policies catch API submissions, Transform Map imports, and even Business Rule modifications. Use them for audit requirements, regulatory compliance, or when you have external systems writing directly to your tables.

Use UI Policies Instead When

Your validation is purely for user experience and you want dynamic behavior based on form state. UI Policies can hide fields, change labels, and provide real-time visual feedback that Data Policies cannot. They're also better for complex conditional logic that needs to evaluate multiple fields simultaneously. If your rule is "make this field mandatory only when users select option X from dropdown Y," UI Policies handle the dynamic showing/hiding much more elegantly.

Use Both Together When

You need bulletproof validation with good user experience. Create the Data Policy for server-side enforcement and a matching UI Policy for browser-side feedback. The UI Policy provides immediate visual cues and field behavior, while the Data Policy acts as the safety net for API access and imports. This combination gives users helpful real-time guidance while maintaining absolute data integrity.

Platform Interactions & Side Effects

• Business Rules execute after Data Policy validation - if the policy fails, Business Rules never trigger and the record doesn't save
• Transform Maps fail completely when Data Policy violations occur during import - no partial record creation in sys_import_set_row
• REST API calls return HTTP 400 errors with field-specific violation details in the response body under error.detail
• Access Controls (ACLs) evaluate before Data Policies - users need write access to the field before policy validation occurs
• Audit records in sys_audit are not created when Data Policy violations prevent record saves
• Workflow activities that update records will fail and enter error state when they violate active Data Policies
• Email notifications triggered by Business Rules won't send if the Data Policy prevents the record update that should trigger them
• Update Sets capture Data Policy records but not their runtime state - importing policies that were inactive during export may become active unexpectedly
• Performance impact occurs on every insert/update operation as policies evaluate even when conditions exclude the current record
• Session caching doesn't apply to Data Policy evaluation - they execute fresh on every transaction regardless of glide.cache.data_policy settings

Debugging and Troubleshooting

Data Policy failures manifest as form submission errors reading "Field 'field_name' is mandatory" or "Field 'field_name' is read only" with no indication which policy caused the violation. Users see generic error messages regardless of the policy's actual name or description. API integrations receive HTTP 400 responses with the same field-level error text in the JSON response body. Import operations fail silently with error details buried in Transform History records.

For debugging, navigate to System Logs > All and filter by Source contains 'DataPolicy' to see which policies triggered. Enable debug logging by setting com.glide.data_policy to Debug level in System Diagnostics > Log Levels. The debug output shows policy evaluation sequence and condition results, helping identify which specific policy and rule caused the failure.

Look for error messages like "Data policy violation: field 'assignment_group' is mandatory" in system logs. For API failures, examine the REST response body for the exact field mentioned in error details. Import failures appear in sys_import_set_row records with sys_import_state=error and error details in the sys_import_state_comment field.

Diagnostic Checklist:

• Query sys_data_policy table filtering by active=true and your target table name
• Check sys_data_policy_rule for the specific field and mandatory/read-only settings
• Test the policy condition manually using GlideFilter.checkRecord() in Scripts - Background
• Verify table inheritance - check if policy targets parent table when you expected child table only
• Review sys_metadata_delete for recently deleted policies that might still be cached
• Check user ACL access to the field - Data Policy violations can mask underlying permission issues
• Enable session debug and reproduce the issue to capture detailed policy evaluation logs

Quick Reference

• Maximum 100 active Data Policies per table - exceeding this triggers performance warnings in system logs
• Policy conditions evaluate using the current record state, not the submitted values - use current. prefix in condition scripts
• Order field in sys_data_policy controls evaluation sequence - lower numbers run first, default is 100
• Read-only Data Policy rules override mandatory rules - a field cannot be both mandatory and read-only simultaneously
• System administrator role bypasses Data Policies by default when glide.data_policy.enforce_sys_admin is false
• Data Policies apply to journal fields (work_notes, comments) but evaluate against the current journal entry, not historical entries
• Cross-scope applications can create Data Policies that affect global scope tables - no scope isolation for policy enforcement
• Empty string values ("") trigger mandatory field violations, but null values pass mandatory checks on reference fields
• Data Policy evaluation adds approximately 2-5ms per active policy to every database write operation
• Conditions using gs.getUser() or gs.hasRole() work in browser sessions but fail during background processing and imports