Don’t Update System Fields With autoSysFields(false)

When To Use autoSysFields(false)

As a ServiceNow Admin, you’ve most likely experienced this scenario before.

You need to bulk update a few hundred records, by adding a worknote for example, but that’s all you want to do.

You don’t want to update any of the Updated By, or Updated On fields, which you will update if you just run the updates through a background script.

By using object.autoSysFields(false) in a GlideRecord loop, you will be able to add any field update – without changing any of the system fields.

It’s helpful to keep system fields alone sometimes, for reporting purposes.

If you were to go in and update 500 change request records, and you don’t use object.autoSysFields(false), they’re all going to look like they’ve been updated today.

This will likely mess with any filters that users have and usually isn’t the desired impact you’re going for.

When you want to leave system fields alone and you’re running a bulk update via background script – consider using object.autoSysFields(false).

Keep in mind that this is a server side operation and can only be used in a business rule or background script – it’s not possible to implement this feature on the client.

Don’t Update System Fields

For better understand this GlideRecord Method, let’s consider the following use case.

The Change Manager wants to add a worknote to all closed Change Request records.

As a ServiceNow Admin, when we consider a bulk update, we should consider the impact that this will have on our end users. If you were to just write a simple background script to add a work note, that would get the “job done”, but you would be creating a poor user experience. Because you’re username is going to be updated on all of the closed Change Request records, overwriting the actual user (and time of closure) that actually occurred.

So in an attempt to “sneak” into the record, without the system tagging any system fields and just updating the field(s) you want – you can just add one line to your GlideRecord Query.

Here are the 10 out of box Change request records that are closed.

Let’s add a worknote to all of these records, but don’t modify the “Updated” or “Updated By” fields.

To do that, we’ll create a background script.

Script:

var gr = new GlideRecord(“change_request”);
gr.addEncodedQuery(“state=3”);
gr.query();

while (gr.next()) {
gr.work_notes = “Adding a worknote to closed changes”;
gr.autoSysFields(false);
gr.update();
}

As you can see here, we are creating a pretty simple and normal GlideRecord Query.

The only difference is the gr.autoSysFields(false) being added to the query.

I also played around with the above by adding gr.forceUpdate(), along with gr.update();

Consider adding the object.forceUpdate() along with the object.update() if it does not work for you as highlighted above.

When we add the above and run it in a background script, we’ll see that our change request records have now been updated. All of them have a new work note that has been added to the Change.

The benefit here is that the “Updated On” and “Updated By” fields have not been changed.

For example, the above record states that the change was last updated in 2015, but I’ve added a work note nearly 6 years later now in 2021.

Give it a try yourself and see how it goes. The best use case for this Method is in a background script when you need to bulk update records and don’t want to mess with reports. It would look odd if the ServiceNow Admin had randomly gone in and updated thousands of records, or rather – if the system said that you did.

We now know that there is a way around this.

For more GlideRecord API methods, check out the ServiceNow GlideRecord page here.