Unexpected Behavior: Data Policy Bypass After Multiple gr.update() Calls in ServiceNow

[TooManyTabs]

Hey everyone,

I came across an interesting and somewhat unexpected behavior in ServiceNow and wanted to share it with you. Maybe someone here can shed some light on it or has seen something similar.

I was originally trying to create a small helper function that checks whether an update was successful. In case of a failure, the function was supposed to gradually disable setUseEngines(false) or setWorkflow(false) and then log an error or create a defect.

During testing, I noticed something strange:
I performed three consecutive gr.update() calls on a field that is normally read-only due to a Data Policy. Between the second and third call, I toggled setWorkflow(false) and setUseEngines(false). Surprisingly, the update only succeeded on the third attempt.

Things got even more confusing when I removed both setWorkflow(false) and setUseEngines(false) entirely from the script: The update still only succeeds after the third gr.update() – even though the script no longer explicitly bypasses any Data Policy.

It seems that starting with the third update call, the Data Policy is effectively bypassed, even though it shouldn’t be.
Has anyone seen this behavior before or can explain why this might happen?

Below is the test script I used:

function test(){
    var sysId = '<your sys_id>';

    var gr = new GlideRecord('cmdb_ci_server');
    if(gr.get(sysId)){
        gr.setValue('ip_address','1.1.1.1');

        var response = null;

        // 1. First update: Data Policy Exception
        response = gr.update();
        gs.print('First update: ' + response);
        if(!JSUtil.nil(response)) return;

        // 2. Second update: Silent
        response = gr.update();
        gs.print('Second update: ' + response);
        if(!JSUtil.nil(response)) return;

        // 3. Third update: Works???
        response = gr.update();
        gs.print('Third update: ' + response);
        return response;
    }
    return null;
}

gs.print('Overall result: ' + test());

Background output:

Background message, type:error, message: Data Policy Exception: 
	The following fields are read only: IP Address
*** Script: First update: null
*** Script: Second update: null
*** Script: Third update: 376859b53b57441059ff122c85e41a74
*** Script: Overall result: 376859b53b57441059ff122c85e41a74

[Siddhesh Jadhav]

Hi @TooManyTabs 

The issue you are seeing is actually expected GlideRecord behavior.

Cause:
After the first update fails due to the Data Policy, GlideRecord internally clears all dirty fields. This means it no longer thinks anything has changed on the record.

Reason:
When you call gr.update() the second and third time, GlideRecord sees no changes to save, so it skips Data Policy validation entirely and simply returns the existing sys_id.
This creates the illusion that the third update “worked,” but in reality nothing was updated.

Thanks & Regards,
Siddhesh Jadhav

If my explanation helped resolve your query, please mark it as Accepted and Helpful.

[TooManyTabs]

Hi @Siddhesh Jadhav,

Thank you so much for your thoughts.

A few days have passed since my post, and I have tested the script once more in our dev environment.
I can confirm that the third update() does actually update the record.



I have slightly altered the sys_id in the screenshot, but the execution is valid.