Form screen does not recognize field value changes in client script as record updates.

MugTm09 · Monday

I defined a ClientScript to change the items on the incident screen in accordance

with changes to other items.(onchange script)

Unfortunately, the screen does not seem to detect other field changes

made by the script when you revert the field that was manipulated.

Now, if I manually restore the value from what was changed by the client script,

the form screen still recognizes it as "changed" even though it has been restored.

This is an unnatural behavior,

so if anyone has any tips or ideas on how to solve this, I would appreciate your help.

MugTm09 · Tuesday

Hi, Everyone.

I have confirmed that the script below works on the standard UI16 interface but does not work in Workspace.
The fact that it does not work in Workspace is by design, as indicated KB0855260 .

Furthermore, I was unable to find any method or property in Workspace that allows detecting whether changes have occurred.

However, as shown Detecting Form changes in CSM/Agent Workspace - ServiceNow Community,
it seems possible to detect updates.

If anyone knows of a logic that can detect changes in Workspace,

I would greatly appreciate it if you could continue investigating.

At the very least, if you're using the standard UI16 interface,

the implementation below should be helpful.

    var targetKey = "problem.u_custom_choice";
    alert("Before:" + JSON.stringify(g_form.modifiedFields));

    Object.keys(g_form.modifiedFields).forEach(function(key) {
        if (key == targetKey) {
            delete g_form.modifiedFields[key];
        }
    });
    alert("Clean:" + JSON.stringify(g_form.modifiedFields));

    g_form.modifiedFields['problem.u_custom_choice'] = true;
    alert("After:" + JSON.stringify(g_form.modifiedFields));

Regards.

View solution in original post

Ravi Gaurav · Monday

Hi @MugTm09

ServiceNow tracks form changes using its internal g_form.modifiedFields array.
When you change a field via a script (like g_form.setValue()), it updates the UI but doesn’t always sync that change into the modified state tracking - especially if the same field is later changed by the user to the same value.

This leads to the form being in a “dirty” state incorrectly.

-------------------------------------

After your scripted updates, you can reset the modified state:

Use this carefully - it resets tracking for all fields.

If you only want to reset one field:

--------------------------------------------------------------------------------------------------------------------------

If you found my response helpful, I would greatly appreciate it if you could mark it as "Accepted Solution" and "Helpful."
Your support not only benefits the community but also encourages me to continue assisting. Thank you so much!

Thanks and Regards
Ravi Gaurav | ServiceNow MVP 2025,2024 | ServiceNow Practice Lead | Solution Architect
CGI
M.Tech in Data Science & AI

 YouTube: https://www.youtube.com/@learnservicenowwithravi
 LinkedIn: https://www.linkedin.com/in/ravi-gaurav-a67542aa/

Bhimashankar H · Tuesday

Hi @MugTm09 ,

The ServiceNow form “dirty” state is tracked internally. Manual changes update the dirty state logic, but changing a field via client script (e.g., g_form.setValue()) may not always update the form’s internal changed fields list as expected.

You can try setting the form dirty forcefully, just check g_form.modified = true; or set the field has changed

Please refer this below script, check your script if it is correct

onChange client scripts not triggering if onChange field is changed programatically

Thanks,
Bhimashankar H

-------------------------------------------------------------------------------------------------
If my response points you in the right directions, please consider marking it as 'Helpful' & 'Correct'. Thanks!

MugTm09 · Tuesday

Thanks, @Ravi Gaurav @Bhimashankar H .　CC: Everyone.

To check the operation, we wrote that "g_form.modified=true;" and
"g_form.modifiedFields = ['category'];" must be executed

but it did not work on the Yokohama version Workspace screen and UI16 standard screen.
(Tab displayed "c" (change))

Does this implementation still work now?
I would be grateful if you could continue to give me some tips.

MugTm09 · Tuesday

P.S.: I apologize if the explanation is difficult to understand. If it is absolutely "True," then when you restore the value, "c" should continue to be displayed, but it does not.
Also, if you implement it so that it is "False," "c" should not be displayed, but it is displayed.