🎛️ UI Policies and Data Policies in ServiceNow

---

CASE STUDY 1: 🌐 1. Introduction

In ServiceNow, UI Policies and Data Policies are two powerful tools used to control form behavior and enforce data consistency.

• UI Policies → Affect form behavior on the user interface (e.g., making fields mandatory, read-only, or hidden).

• Data Policies → Enforce rules at the data level, ensuring consistency regardless of how data is entered (form, import, API).

💡 Key Difference:

• UI Policy = client-side (UI behavior)

• Data Policy = server-side (data enforcement)

---

📑 2. UI Policies

Definition

UI Policies dynamically change the behavior of fields on forms based on conditions.

What UI Policies Can Do

• Make a field mandatory

• Make a field read-only

• Show or hide a field

• Apply scripts for advanced logic

Example Use Case

• In the Incident Form, if Priority = 1 (Critical):

  • Make “Assignment Group” mandatory.

  • Display a warning message.

UI Policy Scripts

UI Policies can use scripts for advanced control:

function onCondition() {
   g_form.setMandatory('assignment_group', true);
   g_form.setVisible('impact', true);
}

---

📑 3. Data Policies

Definition

Data Policies enforce data consistency rules at the server-side level. They are similar to UI Policies but apply to all data entry points.

What Data Policies Enforce

• Ensure fields are mandatory

• Enforce field read-only restrictions

• Apply rules during:

  • Form submission

  • Import Set transformations

  • Web service/API integrations

Example Use Case

• Ensure “Email” field is mandatory in the User Table (sys_user) regardless of whether the record is created from:

  • Form UI

  • Import Set

  • Integration API

---

CASE STUDY 2: 🔄 Comparison: UI Policy vs Data Policy

Feature	UI Policy	Data Policy
Execution	Client-side (UI)	Server-side (data)
Applies to	Forms only	Forms, Imports, APIs
Enforcement	User Interface	Database-level
Use Case	Improve user experience	Ensure data integrity

💡 Tip:
Use UI Policies for user interface behavior, and Data Policies for enforcing global data integrity.

---

CASE STUDY 3: ⚡ Advanced Concepts

1. UI Policy vs Client Script

   • UI Policies are simpler and preferred over client scripts when possible.

   • Use Client Scripts only for complex logic.

2. Global Enforcement with Data Policies

   • Data Policies enforce rules even when records are created via REST APIs, Imports, or Workflows, ensuring consistency.

3. Read-only Fields Trick

   • Data Policies can make fields read-only in the backend, preventing updates via imports or integrations.

4. Reusability

   • A Data Policy can be reused across multiple forms and integrations, reducing duplication of logic.

⚡ 1. Advanced UI Policies

1.1 Conditions & Multiple Policies

• Multiple UI Policies can be active on a form at the same time.

• If two policies control the same field, priority order matters:

  • “True” conditions override “False” unless scripts modify them.

1.2 Script Logic Extensions

UI Policies come with three lifecycle functions:

1.3 Role-Specific Policies

• You can restrict UI Policies to only apply for certain roles.

• Example: Only make “Financial Impact” field mandatory for users with the finance_analyst role.

⚡ 2. Advanced Data Policies

2.1 Execution Scope

• Data Policies run on all forms and back-end processes.

• They ensure data integrity even when the UI is bypassed.

2.2 Enforcement Options

• Apply to forms only → Behaves like a UI Policy.

• Apply to all data sources → Includes imports, APIs, and background scripts.

2.3 Coexistence with Business Rules

• Data Policies validate input requirements, while Business Rules can enforce workflow logic.

• Example: Data Policy ensures “Email” is not blank; Business Rule validates the email format.

2.4 Example Data Policy Script

 

CASE STUDY 4:🔄  Interaction Between UI & Data Policies

• UI Policy: Enhances user experience by dynamically controlling forms.

• Data Policy: Ensures consistent enforcement regardless of entry method.

Example Combined Use Case:

• UI Policy makes the “Manager Approval” field mandatory if Priority = 1.

• Data Policy ensures even if the record comes via API, “Manager Approval” is enforced.

📊 Troubleshooting & Common Issues

• Issue: Data Policy not working on forms.

  • Fix: Check if “Apply to Forms” option is selected.

• Issue: Conflicts between multiple UI Policies.

  • Fix: Consolidate into a single policy or use scripting for precedence.

• Issue: Users bypassing rules via imports.

  • Fix: Use Data Policy (not UI Policy) to enforce backend validation.

---

🛠️ Real-World Examples

1. UI Policy Example

   • If Category = Hardware, display the “Asset Tag” field on the Incident form.

2. Data Policy Example

   • In HR Case records, Employee ID must always be filled, whether created by HR Agent or imported via HR integration.

3. Hybrid Example

   • UI Policy ensures users see a field as mandatory.

   • Data Policy ensures integrations also enforce it.

---

CASE STUDY 5: 💡 Best Practices

• ✅ Use UI Policies first for form behavior (simpler, better performance).

• ✅ Use Data Policies to enforce data consistency across the platform.

• ✅ Use naming conventions (e.g., DP - User Email Mandatory).

• ✅ Avoid duplicating logic between UI and Data Policies unnecessarily.

• ✅ Test Data Policies with imports and APIs to ensure consistency.

• ❌ Do not rely solely on UI Policies—users can bypass forms via integrations.

---

🎬 Conclusion

UI Policies and Data Policies in ServiceNow work hand-in-hand to ensure:

• UI Policies → Better user experience by dynamically changing forms.

• Data Policies → Strong data integrity across all entry points.