How to Update GlideRecord in ServiceNow While Bypassing Data Policies: A Practical Guide

When developing or maintaining applications on the ServiceNow platform, there are times when updates need to be made to records programmatically using server-side scripts. However, enforcing data policies can interfere with these updates—especially if mandatory fields are not populated, even when business logic deems them unnecessary in the current context.

This article addresses a common challenge: updating a GlideRecord while bypassing ServiceNow data policies. We will explore the limitations, provide tested solutions, and explain how to handle scenarios where backend operations conflict with UI-enforced rules.

Understanding the Problem

In ServiceNow, data policies enforce field requirements regardless of how a record is modified—through the UI, APIs, or background scripts. Unlike UI policies that apply only on forms, data policies extend to server-side logic and integrations. This can pose problems when attempting to update records using background scripts, Business Rules, or fix scripts, especially if some fields marked as mandatory are intentionally left empty.

Consider the following scenario: A script attempts to update all user records without modifying their fields. Even if the update is logically valid, a mandatory field (as enforced by a data policy) may block the update.

What Does Not Work

Many developers attempt the following methods to bypass data policies:

• gr.setWorkflow(false): Disables Business Rules from running, but does not affect data policies.

• gr.autoSysFields(false): Prevents system fields (like updated_by or updated_on) from being modified, but has no impact on data policy enforcement.

• gr.setForceUpdate(true): Forces an update even when field values have not changed, but again, it does not bypass data policies.

  
  

None of these options override the validation imposed by data policies.

Verified Solution: Using setUseEngines(false)

A lesser-known and effective method involves disabling what ServiceNow refers to as “engines”—which include assignment and approval rules, and more importantly, data policies.

To implement this, add the line:

gr.setUseEngines(false);

before the update operation on the GlideRecord instance. This disables data policy validation during that transaction.

Example:

var gr = new GlideRecord('sys_user');
gr.query();
while (gr.next()) {
    gr.setUseEngines(false); // Disable data policies and assignment engines
    gr.setWorkflow(false);   // Prevent Business Rules from executing
    gr.autoSysFields(false); // Avoid system field updates
    gr.setForceUpdate(true); // Ensure update even if data is unchanged
    gr.update();
}

Important Considerations:

• setUseEngines(false) is undocumented or lightly documented, and behavior could potentially vary across platform releases.

• Some users have reported that this method is no longer reliable in more recent versions. If using this method, always test in a non-production environment first.

  
  

Alternative Approaches

If setUseEngines(false) is unavailable or ineffective in your version:

1. Temporarily Deactivate Data Policies

   • Identify and disable the relevant data policies before running the script.

   • Re-enable them after the operation.

   • This should be done only in development or with controlled scripts in lower environments.

     
     

2. Use Import Sets

   • Configure the data policy to skip enforcement during import set runs.

   • Insert or update records using an import set instead of a direct GlideRecord update.

     
     

3. Scoped Overrides with Conditions

   • Modify the data policy script logic to ignore certain updates if a specific condition or context (e.g., system user or script execution) is detected.

     
     

Conclusion

Updating records in ServiceNow via GlideRecord can be complicated when data policies enforce field requirements across all entry points. Fortunately, using gr.setUseEngines(false) allows developers to bypass these constraints in many cases, enabling background scripts and automation to function as intended.

Key Takeaways:

• Data policies apply to both UI and backend updates by default.

• Common GlideRecord methods like setWorkflow and setForceUpdate do not override data policies.

• The setUseEngines(false) method can disable data policy enforcement during script execution.

• Always test such scripts thoroughly in development environments before applying in production.