Understanding current.update() and setWorkflow(false)
Introduction
When a user updates a record in ServiceNow, the platform does a lot of things automatically.
It runs Business Rules. It triggers Flows. It sends Notifications. It fires Events.
This is normal. This is how ServiceNow is supposed to work.
But sometimes, as a developer, you need more control. Maybe you want to save a record from inside a script. Or maybe you want to update a record without sending out emails or triggering workflows.
For these situations, ServiceNow gives you two methods:
This guide explains what these methods do, when to use them, and how to avoid common mistakes.
1. What is current.update()?
current.update() saves the record again from inside a script.
That is it. Simple.
When you call it, the platform behaves exactly like a user clicked the Update button. Everything runs — Business Rules, Flows, Notifications, everything.
Example
current.short_description = "Updated by script";
current.update();
Here is what happens step by step:
1. The short description field gets a new value.
2. current.update() saves the record.
3. All automation runs again — just like a normal save.
This is useful. But it can also cause problems if you are not careful.
2. The Recursion Problem
This is the most common mistake developers make.
Imagine you write a Business Rule. It runs After a record is updated. Inside that Business Rule, you call `current.update()`.
Here is what happens:
1. User updates the record.
2. Your After Business Rule runs.
3. Your script calls `current.update()`.
4. The record saves again.
5. Your After Business Rule runs again.
6. Your script calls `current.update()` again.
7. This keeps going forever.
This is called recursion. It is basically an infinite loop.
What You Will See
- The form freezes after clicking Update.
- The loading spinner never stops.
- The browser becomes very slow.
- System logs show the same Business Rule running over and over.
The Script That Causes This
ServiceNow Code
// Do NOT write thisif (current.u_mark_resolved) {
current.update(); // This will loop forever
}
Every time the record saves, the condition is still true. So `current.update()` runs again. And again. And again.
3. What is setWorkflow(false)?
setWorkflow(false)tells ServiceNow to save the record quietly.
No Business Rules. No Workflows. No Flows. No Notifications. No Events.
Just a plain, silent save.
Example
ServiceNow Code
current.setWorkflow(false);current.update();
One important thing to remember — always call setWorkflow(false)
before current.update(). If you call it after, it will not work.
4. How to Fix the Recursion Problem
There are two simple ways to fix recursion.
Fix 1 — Use setWorkflow(false)
When you use `setWorkflow(false)` before the update, Business Rules will not run on that second save. So the loop stops.
ServiceNow Code
//This is safe
if (current.u_mark_resolved) {
current.state = 7;
current.setWorkflow(false);
current.update();
}
The record saves. No Business Rules fire. No loop.
Fix 2 — Check if the Field Actually Changed
ServiceNow gives you a previous object. It holds the field values from before the save happened.
You can use it to check if the field truly changed — not just whether it is currently true.
ServiceNow Code
//This is also safe
if (current.u_mark_resolved && !previous.u_mark_resolved) {
current.state = 7;
current.setWorkflow(false);
current.update();
}Now the Business Rule only runs once — when the checkbox changes from false to true. It will not run again on the second save because the field did not change a second time.
Using both fixes together is the safest approach.
5. Real Examples You Will Actually Use
Example 1 — Auto-Close an Incident
A support agent checks the "Mark Resolved" checkbox. You want the incident to automatically move to Closed state.
ServiceNow Code
if (current.u_mark_resolved && !previous.u_mark_resolved) { current.state = 7; // 7 means Closed
current.setWorkflow(false);
current.update();
}
The incident closes. No emails go out. No loop happens.
Example 2 — Update Thousands of Records at Once
Say you need to add a flag to all open incidents. Running full automation on thousands of records would send thousands of emails and slow down the system badly.
ServiceNow Code
var gr = new GlideRecord('incident');gr.addQuery('state', 1);
gr.query();
while (gr.next()) {
gr.u_bulk_processed = true;
gr.setWorkflow(false);
gr.update();
}
All records update quietly. No notifications. No workflows. No slowdown.
Example 3 — Change Priority Without Notifying Anyone
Sometimes you change a field as part of a background process. You do not want a notification to go out every time.
ServiceNow Code
current.priority = 2;current.setWorkflow(false);
current.update();
The priority changes. No one gets an email.
Example 4 — Importing Data From Another System
When you are migrating data or syncing records from an external tool, you do not want old workflows firing on every imported record.
ServiceNow Code
current.assignment_group.setDisplayValue("Network Operations");current.setWorkflow(false);
current.update();
Data comes in clean. No unwanted automation runs.
6. Best Practices to Follow
These are simple rules that experienced ServiceNow developers follow.
Use Before Business Rules when you just need to change a field.
Before Business Rules run before the record saves. You can change field values there without needing to call `current.update()` at all. This is always the simpler option.
Avoid current.update() inside After Business Rules.
After Business Rules run after the save. Calling `current.update()` there means the record saves twice. Think carefully before doing this.
If you must use current.update() in an After Business Rule, always add setWorkflow(false).
This is not optional. Without it, you risk an infinite loop every single time.
Always use the previous object to check field changes.
Do not just check if the field is true or false right now. Check if it changed. This prevents your logic from running more than once.
Always use setWorkflow(false) in bulk update scripts.
If your script loops through many records, suppressing automation is a must. The alternative — thousands of emails and workflows firing at once — can seriously harm your instance.
8. A Simple Way to Remember This
Think of `current.update()` as pressing the Save button yourself from inside the code. Everything that normally happens on save will happen again.
Think of `setWorkflow(false)` as pressing Save but putting up a "Do Not Disturb" sign first. The record saves, but nothing else wakes up.
Together, they give you full control over how and when records are saved — without causing problems for the rest of the system.
