ServiceNow Business Rules vs Data Policies: Complete Comparison Guide

Understanding when to use Business Rules versus Data Policies is essential for ServiceNow CSA certification and effective platform administration. While both execute server-side, they serve fundamentally different purposes. This comprehensive guide will clarify the differences and help you choose the right tool.

Quick Comparison Overview

Business Rules: The Automation Engine

What Are Business Rules?

Business Rules are server-side scripts that execute automatically when database operations occur. They're the primary automation tool in ServiceNow.

Key Characteristics:

• Server-side execution - Run on ServiceNow servers
• JavaScript-based - Write custom logic and code
• Full database access - Query and modify any records
• Four execution timings available:
  • Before - Before database operation (can modify current record)
  • After - After database operation (can create related records)
  • Async - After commit, runs in background
  • Display - When form loads or record queried

What Business Rules Can Do:

1. Modify Field Values

   • Calculate fields based on other field values
   • Set default values automatically
   • Copy data from related records

2. Query and Update Other Records

   • Create related records (tasks, approvals)
   • Update parent/child records
   • Aggregate data from multiple records

3. Execute Complex Logic

   • Conditional workflows
   • Multi-step calculations
   • Business process automation

4. Trigger Integrations

   • Call external APIs
   • Send data to other systems
   • Process webhooks

5. Validation with Prevention

   • Validate data AND prevent save if invalid
   • Custom error messages
   • Complex validation logic

Business Rule Example 1: Auto-Populate Department

Scenario: When an incident is created, automatically set the department based on the caller's department.

// Business Rule: Auto-set Department
// When: before
// Insert: true
// Table: Incident

(function executeRule(current, previous /*null when async*/) {
    // Query the caller's user record to get their department
    if (current.caller_id) {
        var caller = current.caller_id.getRefRecord();
        if (caller && caller.department) {
            current.u_department = caller.department;
        }
    }
})(current, previous);

What This Does:

• Executes BEFORE the incident is saved
• Queries the caller's user record
• Copies their department to the incident
• No user interaction needed

Business Rule Example 2: Create Follow-up Task

Scenario: When a high-priority incident is resolved, automatically create a follow-up task.

// Business Rule: Create Follow-up Task
// When: after
// Update: true
// Table: Incident
// Condition: priority = 1 AND state = 6 (Resolved)

(function executeRule(current, previous /*null when async*/) {
    // Only create task if state changed to Resolved
    if (current.state == 6 && previous.state != 6) {
        var task = new GlideRecord('task');
        task.initialize();
        task.parent = current.sys_id;
        task.short_description = 'Follow-up: ' + current.short_description;
        task.description = 'Review resolution for high-priority incident';
        task.assigned_to = current.resolved_by;
        task.insert();
        
        gs.addInfoMessage('Follow-up task created');
    }
})(current, previous);

What This Does:

• Executes AFTER the incident is saved
• Checks if state changed to Resolved
• Creates a new task record in the database
• Links it to the parent incident

Business Rule Example 3: Calculate SLA

Scenario: Calculate business hours between incident creation and resolution.

// Business Rule: Calculate Resolution Time
// When: before
// Update: true
// Table: Incident
// Condition: state = 6 (Resolved) AND resolved_at is empty

(function executeRule(current, previous /*null when async*/) {
    if (current.state == 6 && current.resolved_at.nil()) {
        // Set resolved timestamp
        current.resolved_at = new GlideDateTime();
        
        // Calculate business hours
        var schedule = new GlideSchedule();
        schedule.load(current.assignment_group.schedule);
        
        var duration = schedule.duration(
            current.opened_at,
            current.resolved_at
        );
        
        current.u_business_hours_to_resolve = duration.getNumericValue() / 3600; // Convert to hours
    }
})(current, previous);

What This Does:

• Executes BEFORE saving the resolved incident
• Sets the resolved timestamp
• Calculates business hours using schedule
• Stores the result in a custom field

Data Policies: The Validation Guardian

What Are Data Policies?

Data Policies enforce data integrity rules by making fields mandatory or read-only, regardless of how data enters the system.

Key Characteristics:

• Server-side validation - Cannot be bypassed
• Configuration-based - No coding required
• Limited to field control - Only mandatory/read-only
• Universal enforcement - Works for:
  • Form submissions
  • Web service calls (REST/SOAP)
  • Import sets
  • Server-side scripts
  • Any data modification

What Data Policies Can Do:

1. Enforce Mandatory Fields

   • Require specific fields before save
   • Conditional requirements based on other fields
   • Universal enforcement (all entry methods)

2. Protect Fields (Read-only)

   • Prevent modification of critical fields
   • Lock fields after certain conditions
   • Protect audit trails

3. Conditional Validation

   • Apply rules based on field values
   • Role-based requirements
   • State-based enforcement

What Data Policies CANNOT Do:

❌ Cannot modify field values (use Business Rules) ❌ Cannot query other records (use Business Rules) ❌ Cannot execute custom logic (use Business Rules) ❌ Cannot hide/show fields (use UI Policies) ❌ Cannot clear field values (use UI Policies)

Data Policy Example 1: Mandatory Approval

Scenario: Require manager approval for all critical priority incidents.

Configuration:

• Table: Incident
• Conditions: Priority is 1 - Critical
• Data Policy Rules:
  • Field: Approval
  • Type: Mandatory
  • Condition: (none - always required)

What This Does:

• Validates on save (form, API, import, script)
• Prevents save if Approval is empty
• Shows error message to user
• Cannot be bypassed by any method

Data Policy Example 2: Protect Closed Records

Scenario: Prevent modification of incidents once they're closed.

Configuration:

• Table: Incident
• Conditions: State is 7 - Closed
• Data Policy Rules:
  • Field: * (all fields)
  • Type: Read-only
  • UI: Visible

What This Does:

• Makes all fields read-only when state is Closed
• Prevents updates via any method
• Maintains audit trail integrity
• Enforces business rule

Data Policy Example 3: Conditional Requirements

Scenario: Require resolution notes when incident is resolved.

Configuration:

• Table: Incident
• Conditions: State is 6 - Resolved
• Data Policy Rules:
  • Field: Close notes
  • Type: Mandatory

What This Does:

• Validates only when state is Resolved
• Requires close notes before save
• Universal enforcement
• Simple configuration, no code

When to Use Business Rules

✅ Use Business Rules When:

1. You Need to Modify Data

   • Calculate field values
   • Set defaults based on logic
   • Copy data from related records

2. You Need to Query Records

   • Check conditions in other tables
   • Aggregate data from multiple records
   • Update parent/child records

3. You Need Complex Logic

   • Multi-step workflows
   • Conditional processing
   • Integration with external systems

4. You Need to Create Records

   • Generate related tasks
   • Create approval records
   • Spawn child records

5. You Need Timing Control

   • Before save modifications
   • After save actions
   • Async background processing
   • Display-time calculations

Business Rule Best Practices:

1. Choose the Right Timing

   • Before for modifying current record
   • After for creating related records
   • Async for heavy processing
   • Display for query-time calculations

2. Optimize Performance

   • Minimize database queries
   • Use GlideRecord efficiently
   • Avoid nested loops
   • Consider async for heavy operations

3. Error Handling

   • Use current.setAbortAction(true) to prevent save
   • Provide clear error messages with gs.addErrorMessage()
   • Log errors for debugging

4. Conditions Matter

   • Use filter conditions to limit execution
   • Check field changes: current.field.changes()
   • Avoid unnecessary execution

When to Use Data Policies

✅ Use Data Policies When:

1. You Need Guaranteed Enforcement

   • Critical business rules
   • Compliance requirements
   • Regulatory mandates

2. Data Comes from Multiple Sources

   • REST/SOAP APIs
   • Import sets
   • Integrations
   • Web services

3. You Need Mandatory Fields

   • Required fields for data integrity
   • Conditional requirements
   • Simple validation rules

4. You Need Read-only Protection

   • Protect audit fields
   • Lock closed records
   • Prevent unauthorized changes

5. You Want Simple Configuration

   • No coding required
   • Easy to maintain
   • Quick to implement

Data Policy Best Practices:

1. Keep It Simple

   • Use for validation only
   • Don't try to automate with data policies
   • Let Business Rules handle logic

2. Provide Clear Messages

   • Configure helpful error messages
   • Explain why validation failed
   • Guide users to correct input

3. Test All Entry Methods

   • Verify form submissions
   • Test API calls
   • Validate import processes

4. Layer with UI Policies

   • UI Policy for user experience (real-time feedback)
   • Data Policy for security (guaranteed enforcement)

Combining Business Rules and Data Policies

For robust implementations, often use both together:

Example: Critical Incident Workflow

Requirement:

• High-priority incidents need manager approval
• System should auto-notify managers
• Approval cannot be bypassed

Solution:

Business Rule (Automation):

// When: after, Insert: true, Condition: priority = 1
(function executeRule(current, previous) {
    // Auto-create approval record
    var approval = new GlideRecord('sysapproval_approver');
    approval.initialize();
    approval.sysapproval = current.sys_id;
    approval.approver = current.assignment_group.manager;
    approval.insert();
    
    // Send notification
    gs.eventQueue('incident.approval.needed', current, 
                  current.assignment_group.manager, '');
})(current, previous);

Data Policy (Enforcement):

• Table: Incident
• Condition: Priority = 1 - Critical
• Rule: Approval field = Mandatory

Result:

• Business Rule automates approval creation and notification
• Data Policy enforces that approval must be captured
• Complete solution: automation + validation

Common Mistakes to Avoid

❌ Mistake 1: Using Business Rules for Simple Validation

Wrong Approach:

// Business Rule to make field mandatory
if (current.priority == 1 && current.approval.nil()) {
    gs.addErrorMessage('Approval required for critical incidents');
    current.setAbortAction(true);
}

Better Approach: Use a Data Policy (no code needed)

❌ Mistake 2: Trying to Automate with Data Policies

Wrong: Expecting Data Policies to set field values or query records Right: Use Business Rules for any automation or data modification

❌ Mistake 3: Forgetting About Bypasses

Problem: Only using UI Policies for critical validation Solution: Layer Data Policies to prevent API/import bypasses

❌ Mistake 4: Over-Complex Business Rules

Wrong: Single business rule doing too many things Better: Break into multiple focused business rules with clear purposes

Real-World Scenarios

Scenario 1: Incident Assignment

Requirement:

• Auto-assign incidents based on category
• Ensure assigned_to is never empty
• Update assignment group automatically

Solution:

Business Rule (Automation):

// Auto-assign based on category
if (current.category == 'network') {
    current.assignment_group = 'Network Team';
    current.assigned_to = 'default.network.user';
}

Data Policy (Validation):

• Make assigned_to mandatory
• Make assignment_group mandatory

Scenario 2: Change Management

Requirement:

• Changes need approval before implementation
• Prevent changes to approved records
• Auto-calculate risk

Solution:

Business Rule 1 (Calculate Risk):

// Calculate risk score
current.risk = calculateRisk(
    current.impact,
    current.urgency,
    current.u_complexity
);

Business Rule 2 (Create Approval):

// Create approval for high-risk changes
if (current.risk >= 8) {
    createApprovalRecord(current);
}

Data Policy (Protection):

• Make approval mandatory when risk >= 8
• Make all fields read-only when state = Approved

CSA Exam Tips

Key Points to Remember:

Business Rules:

• ✅ Server-side JavaScript automation
• ✅ Can query and modify database
• ✅ Four timings: before, after, async, display
• ✅ Use for calculations, workflows, integrations
• ✅ Can prevent save with setAbortAction()

Data Policies:

• ✅ Server-side validation only
• ✅ Cannot be bypassed (enforced universally)
• ✅ Mandatory and read-only fields only
• ✅ No coding - configuration only
• ✅ Execute on insert/update

Common Exam Questions:

Q: "How do you automatically populate a field based on another table?" A: Business Rule (needs to query database)

Q: "How do you ensure a field is required for all data entry methods?" A: Data Policy (universal enforcement)

Q: "What executes before a record is saved to the database?" A: Business Rule with "before" timing

Q: "Can Data Policies execute custom JavaScript?" A: No (configuration only, no scripting)

Q: "What prevents unauthorized modification of closed incidents?" A: Data Policy with read-only fields

Decision Tree

Use this flowchart to decide which to use:

START: What do you need to do?

├─ Need to MODIFY data or RUN LOGIC?
│  └─ Use BUSINESS RULE
│     ├─ Modify current record? → Before Business Rule
│     ├─ Create related records? → After Business Rule
│     ├─ Heavy processing? → Async Business Rule
│     └─ Display-time calculation? → Display Business Rule
│
└─ Need to VALIDATE or ENFORCE field requirements?
   └─ Use DATA POLICY
      ├─ Make fields required? → Data Policy (Mandatory)
      ├─ Prevent field changes? → Data Policy (Read-only)
      └─ Critical validation? → Data Policy + Business Rule

Quick Reference Card

Choose Business Rules For:

• 🔧 Automation and workflows
• 🔍 Database queries
• 📝 Field calculations
• 🔄 Creating related records
• 🌐 External integrations
• ⚙️ Complex logic and conditions
• 📊 Aggregating data

Choose Data Policies For:

• ✅ Mandatory field enforcement
• 🔒 Read-only field protection
• 🛡️ Data integrity rules
• 🚫 Universal validation (API/form/import)
• 📋 Compliance requirements
• 🔐 Security enforcement
• ⚡ Simple, no-code validation

Conclusion

Understanding the difference between Business Rules and Data Policies is crucial for ServiceNow CSA success:

Business Rules = DO things (automation, calculations, queries) Data Policies = ENFORCE things (validation, requirements)

Best Practice: Use Business Rules for automation and logic, Data Policies for validation and enforcement. For critical business requirements, use both in a layered approach:

1. Business Rule automates the process
2. Data Policy enforces the requirement
3. Result = Robust, maintainable solution

Master these concepts and you'll be well-prepared for the CSA exam and real-world ServiceNow administration!

Practice Questions

Test your understanding:

1. You need to automatically copy a user's location to a new incident. What do you use?

   • Answer: Business Rule (needs to query user table)

2. You need to ensure incidents cannot be modified after being closed. What do you use?

   • Answer: Data Policy (read-only enforcement)

3. You need to create an approval record when priority is critical. What do you use?

   • Answer: Business Rule (needs to create new record)

4. You need to make "Work notes" mandatory when resolving incidents. What do you use?

   • Answer: Data Policy (simple validation)

5. You need to calculate and set a risk score based on impact and urgency. What do you use?

   • Answer: Business Rule (needs calculation logic)

---

Ready to test your knowledge? Practice with our Business Rules and Data Policies questions in the Tests section.