ServiceNow UI Policies vs Data Policies: When to Use Each

One of the most commonly confused topics for ServiceNow administrators is understanding when to use UI Policies versus Data Policies. This guide will clarify the differences and help you choose the right tool for your requirements.

Overview: What's the Difference?

Both UI Policies and Data Policies control field behavior on forms, but they work in fundamentally different ways:

UI Policies: Client-Side Control

What are UI Policies?

UI Policies are client-side rules that dynamically change form behavior in real-time as users interact with forms.

Key Characteristics:

• Run in the browser (client-side)
• Execute immediately when conditions are met
• Provide instant feedback to users
• Only affect the form UI - can be bypassed by:
  • Web service calls (REST/SOAP APIs)
  • Import sets
  • Server-side scripts (Business Rules)
  • Direct database updates

What UI Policies Can Do:

1. Make fields mandatory

   • Dynamically require fields based on conditions
   • Example: Require "Approval" field when Priority is "Critical"

2. Make fields read-only

   • Lock fields to prevent editing
   • Example: Make "Resolved" fields read-only when State is "Closed"

3. Make fields visible/hidden

   • Show or hide fields conditionally
   • Example: Hide "Resolution notes" until State is "Resolved"

4. Clear field values

   • Automatically clear field contents when conditions change
   • Example: Clear "Approval" field when Priority changes from "Critical"

UI Policy Structure:

Conditions (If):

• Define when the policy should activate
• Can use field values, user roles, or other conditions

Actions (Then):

• Define what happens to fields
• Can affect multiple fields at once

Example UI Policy:

Scenario: Make "Approval" field mandatory when Priority is 1-Critical

Configuration:

• Table: Incident
• Condition: Priority is 1 - Critical
• UI Policy Actions:
  • Field: Approval
  • Mandatory: true

Result: When user sets Priority to "1 - Critical", the Approval field immediately becomes required (red asterisk appears).

Data Policies: Server-Side Enforcement

What are Data Policies?

Data Policies are server-side rules that enforce data integrity regardless of how data enters the system.

Key Characteristics:

• Run on the server (server-side)
• Execute on form submit or data update
• Cannot be bypassed - enforced for:
  • Form submissions
  • Web service calls (REST/SOAP APIs)
  • Import sets
  • Server-side scripts
  • Any data modification

What Data Policies Can Do:

1. Make fields mandatory

   • Enforce required fields
   • Prevents record save if not populated

2. Make fields read-only

   • Prevent field updates
   • Useful for audit fields or locked data

3. No visibility control

   • Cannot hide/show fields (UI Policies only)

Data Policy Structure:

Conditions (If):

• Define when the policy should be enforced
• Can use field values, user roles, or other conditions

Rules (Then):

• Define field requirements
• Apply to specific fields

Example Data Policy:

Scenario: Enforce "Approval" field when Priority is 1-Critical from ANY source

Configuration:

• Table: Incident
• Condition: Priority is 1 - Critical
• Data Policy Rules:
  • Field: Approval
  • Mandatory: true

Result: Any attempt to save an incident with Priority "1 - Critical" without an Approval value will fail, regardless of source (form, API, import, etc.).

When to Use UI Policies

Use UI Policies When:

✅ You want immediate user feedback

• Real-time form changes as users type
• Instant visual cues (red asterisks, grayed-out fields)

✅ You want to show/hide fields

• Simplify forms by hiding irrelevant fields
• Progressive disclosure based on selections

✅ You want better user experience

• Prevent users from filling out fields that will become read-only
• Guide users through form completion

✅ Data entry is primarily through forms

• Most users interact through the ServiceNow UI
• Web services and imports are rare or controlled

✅ You want to clear field values dynamically

• Reset fields when conditions change
• Remove outdated selections

UI Policy Best Practices:

1. Keep conditions simple

   • Complex conditions slow down the browser
   • Test performance with many policies

2. Minimize policy actions

   • Each action requires processing
   • Consolidate related actions when possible

3. Order matters

   • Policies run in order by Order field
   • Lower order numbers run first
   • Set appropriate execution order

4. Use "Execute on server"

   • Check this if the policy needs to run when form loads
   • Useful for initial state setup

When to Use Data Policies

Use Data Policies When:

✅ You need guaranteed data integrity

• Critical business rules that cannot be bypassed
• Regulatory or compliance requirements

✅ Data comes from multiple sources

• Web services (REST/SOAP APIs)
• Import sets from external systems
• Server-side scripts
• Integrations

✅ You want to enforce read-only fields

• Prevent modification of audit fields
• Lock data after certain states

✅ Security is critical

• Protect sensitive fields from unauthorized changes
• Enforce mandatory fields for compliance

✅ Data validation on save

• Final validation before committing to database
• Catch issues regardless of entry method

Data Policy Best Practices:

1. Use for critical validations only

   • Don't overuse - UI Policies are better for UX
   • Reserve for must-have data integrity rules

2. Provide clear error messages

   • Users need to understand why save failed
   • Configure helpful validation messages

3. Consider performance

   • Data Policies run on every save
   • Complex policies can slow down saves

4. Test with all entry methods

   • Verify enforcement via forms
   • Test with web services
   • Validate with import sets

5. Document business reasons

   • Explain why the policy is necessary
   • Future admins need context

Common Use Cases

Use Case 1: Priority-Based Requirements

Requirement: High-priority incidents need manager approval

Solution: Use BOTH

• UI Policy: Make Approval field visible and mandatory when Priority is High (immediate feedback)
• Data Policy: Enforce Approval requirement for high-priority incidents (prevent bypass)

Use Case 2: Progressive Form Disclosure

Requirement: Show additional fields based on category selection

Solution: UI Policy ONLY

• Show/hide fields based on Category
• No data policy needed (no integrity risk)
• Pure UX improvement

Use Case 3: API Data Validation

Requirement: Prevent external systems from creating incomplete records

Solution: Data Policy ONLY

• Enforce mandatory fields for API submissions
• UI Policy won't help (bypassed by APIs)
• Data integrity critical

Use Case 4: Closed Incident Protection

Requirement: Prevent changes to closed incidents

Solution: Use BOTH

• UI Policy: Make fields read-only when State is Closed (UX)
• Data Policy: Enforce read-only when State is Closed (prevent bypass via API)

Execution Flow

Understanding when each policy type executes helps choose the right tool:

UI Policy Execution:

1. User loads form → UI Policies run immediately
2. User changes field → Related UI Policies run
3. Form updates in real-time
4. User can see validation before submitting

Data Policy Execution:

1. User loads form → No execution
2. User changes fields → No execution
3. User clicks Submit → Data Policies execute
4. Validation errors shown if policies violated
5. Form submit blocked if violations exist

Combining UI Policies and Data Policies

For critical business rules, use BOTH:

The Layered Approach:

Layer 1: UI Policy (User Experience)

• Provide immediate feedback
• Guide users to correct input
• Improve form usability

Layer 2: Data Policy (Data Integrity)

• Enforce rules server-side
• Prevent bypass through APIs or imports
• Guarantee data quality

Example: Critical Incident Approval

UI Policy:

• Table: Incident
• Condition: Priority is 1-Critical
• Actions: Make Approval mandatory, visible

Data Policy:

• Table: Incident
• Condition: Priority is 1-Critical
• Rules: Approval is mandatory

Result:

• Users see Approval requirement immediately (UI Policy)
• APIs cannot bypass requirement (Data Policy)
• Complete protection with good UX

Troubleshooting Tips

UI Policy Not Working?

Check:

1. Conditions are met - Print field values to verify
2. Policy is active - Check Active checkbox
3. Order value - Lower numbers run first
4. Global vs. specific - Global policies run everywhere
5. Browser cache - Clear cache and refresh
6. Script errors - Check browser console for JavaScript errors

Data Policy Not Working?

Check:

1. Conditions are correct - Test with exact data
2. Policy is active - Verify Active checkbox
3. User has required role - Check role requirements
4. Error message displayed - Look for validation messages
5. Multiple policies conflict - Review all data policies on table

CSA Exam Tips

For the ServiceNow CSA exam, know these key points:

UI Policies:

• ✅ Run client-side (in browser)
• ✅ Execute in real-time
• ✅ Can make fields mandatory, read-only, visible/hidden
• ✅ Can be bypassed by web services, imports, scripts
• ✅ Best for user experience

Data Policies:

• ✅ Run server-side
• ✅ Execute on form submit
• ✅ Can make fields mandatory or read-only (not hidden)
• ✅ Cannot be bypassed
• ✅ Best for data integrity

Common Exam Questions:

• "When do UI Policies execute?" (Answer: Client-side, in real-time)
• "Can Data Policies be bypassed by web services?" (Answer: No)
• "Which policy type can hide fields?" (Answer: UI Policies only)
• "When do Data Policies execute?" (Answer: Server-side, on save)

Quick Decision Tree

Use this flowchart to decide which to use:

Start: Do you need to hide/show fields?
├─ Yes → Use UI Policy
└─ No → Does data come from APIs/imports?
    ├─ Yes → Use Data Policy (+ UI Policy for UX)
    └─ No → Is real-time feedback important?
        ├─ Yes → Use UI Policy (+ Data Policy for security)
        └─ No → Use Data Policy

Practical Exercises

Exercise 1: Create a UI Policy

1. Navigate to System UI > UI Policies
2. Click New
3. Set Table: Incident
4. Set Condition: Priority is 1 - Critical
5. In UI Policy Actions:
   • Set Field: Approval
   • Check Mandatory
6. Test on an Incident form

Exercise 2: Create a Data Policy

1. Navigate to System Policy > Data Policies
2. Click New
3. Set Table: Incident
4. Set Condition: Priority is 1 - Critical
5. In Data Policy Rules:
   • Set Field: Approval
   • Check Mandatory
6. Test by submitting form AND via REST API

Exercise 3: Compare Enforcement

1. Create an incident with Priority = 1-Critical
2. Leave Approval empty
3. Try to save via form (both policies stop you)
4. Try to update via REST API:
   • UI Policy won't stop it
   • Data Policy will stop it

Conclusion

Understanding when to use UI Policies versus Data Policies is crucial for effective ServiceNow administration:

UI Policies = User Experience (Client-side, Real-time, Can be bypassed) Data Policies = Data Integrity (Server-side, On save, Cannot be bypassed)

Best Practice: Use UI Policies for better user experience and Data Policies for guaranteed data integrity. For critical business rules, use both in a layered approach.

Master these concepts for CSA exam success and to build robust ServiceNow applications that are both user-friendly and secure.

Related Topics

• Client Scripts for Advanced Form Behavior
• Business Rules vs Data Policies
• ACLs and Field-Level Security
• Form Design Best Practices

---

Practice your knowledge with our UI Policy and Data Policy questions in the Tests section.