When you’re performing bulk operations via script, you want to make sure that you keep “data integrity” in mind, of the records and tables you’re updating.
You want to make the data as real and usable as possible, for those teams that rely on the data.
So for example, if you’re writing a background script to update 10,000 incidents that were created last year, to just update one (or multiple) field’s value(s) – you don’t want anything else to happen to those 10,000. Specifically, you don’t want business rules or workflows running, based off of your bulk update. When you find yourself in this situation, you’re going to find the ServiceNow GlideRecord method setWorkflow(false), very useful.
In summary, ServiceNow Developers can use setWorkflow(false), to make sure that when they perform a bulk operation via background script, that no other business rules or workflows are executed, which could kick off a series of events that were unintended. It is to be used when you want to explicitly perform a scripted set of actions, and you don’t want other processes in the background of ServiceNow to get kicked off.
Using setWorkflow(false) is very commonly used with another ServiceNow method of autoSysFields(false), which we’ve covered in another post, if you want to take a look:
Let’s dive into an example below, of how to properly use setWorkflow(false)
When To Use setWorkflow(false)
We want to update every incident that was created last month, an add a worknote. We don’t want to interfere with any existing workflows, and we also don’t want to kick off or trigger any of the other business rules that we have on the incident table, that may be responsible for setting dates, resolution times, etc that could impact our SLA’s.
So you can use setWorkflow(false), in the following manner.
Also, be aware that the parameter that this method accepts is a boolean (true, false), but I’ve never really seen a useful way of passing (true), as such setWorkflow(true). Because the system is going to automatically run business rules and workflows.
If you know of a good use case (or any use case at all) of writing object.setWorkflow(true), we'd love to hear it in the comments below, happy to learn something new.
When using setWorkflow(false), you’ll almost always be using it in a while loop, as you’re updating records, one at a time. You put it right before the object.update() line, as shown below:
var gr = new GlideRecord("incident");
gr.addEncodedQuery("sys_created_onONLast month@javascript:gs.beginningOfLastMonth()@javascript:gs.endOfLastMonth()");
gr.query();
while (gr.next()) {
gr.work_notes = "Adding a worknote here";
gr.setWorkflow(false);
gr.update();
}
When the above script is run, it will update every single incident record that was created in the prior month, it will add a worknote to the incident and it will NOT execute any other business rule that sits on the incident table. It is executed every time we iterate over a new row, that’s being returned from a GlideRecord object.
As you can see, we’ve got gr.setWorkflow(false), right after the gr.work_notes field update and before gr.update().
There are hundreds of business rules in your system, and they usually run when a record is inserted or updated.
The above background script will not execute these rules, even if they’re active and have update=true, selected. It will skip over all of these business rules.
It’s also worth mentioning that setWorkflow(false) is almost always run in a background script. We also see it a lot when you’re calculating a certain Glide Date or Glide Date Time field, and you don’t want other business rules to run that are related to dates and time, which can get super messy.
This environment just makes the most sense.
You won’t commonly see this in a business rule.
Let us know how you’ve used it before below.
