Recently, I ran into a strange issue in ServiceNow — for a single update, the system was sending duplicate notifications. At first, it looked like a notification configuration problem, but after digging deeper, the real culprit was unexpected: multiple current.update() calls triggering the same logic repeatedly. This wasn’t just a one-off mistake — I’ve seen this pattern quite often, where developers use current.update() without fully understanding its impact. Even worse, many assume using it in an after Business Rule is safe, which is not true. That experience pushed me to break this down clearly, because this is one of those small things in ServiceNow that can quietly create big problems if handled the wrong way.
If you’ve worked with ServiceNow scripting long enough, you’ve probably written this line without thinking twice:
current.update();Looks harmless, right?
It’s not.
In fact, this one line has quietly broken more implementations than most developers realize.
Let’s unpack why.
The Trap: “Just Update the Record”
Imagine this:
You’re inside a Business Rule.
You want to update a field.
So you write:
current.priority = 1;
current.update();Simple. Clean. Done.
But what actually happens behind the scenes?
- The record updates
- Business Rules run again(Twice)
- Flows trigger
- Notifications fire
And guess what?
👉 Your same Business Rule runs again.
And again.
And again.
Welcome to the infinite loop you didn’t see coming.
Why This Happens
In ServiceNow, every update is treated as a fresh transaction.
So when you call:
current.update();You are essentially telling the system:
“Hey, pretend this record was just updated normally… and run EVERYTHING again.”
That includes:
- Before Business Rules
- After Business Rules
- Async Rules
- Flows & Workflows
No exceptions.
Enter the Hero: setWorkflow(false)
Now here’s where things get interesting.
ServiceNow gives you a way to say:
“Update this record… but don’t trigger all the chaos.”
That’s exactly what this does:
current.setWorkflow(false);The Safe Way to Update
When you combine both:
current.setWorkflow(false);
current.update();You’re telling ServiceNow:
- Update the record
- Don’t trigger Business Rules
- Don’t trigger workflows
- Don’t send notifications
In short: silent update
Real-World Scenario (Where This Matters)
Let’s say you’re running a background fix script.
You want to clean up 10,000 records.
If you do this:
current.update();You might accidentally:
- Trigger thousands of emails
- Run heavy logic repeatedly
- Slow down the instance
But if you do this:
current.setWorkflow(false);
current.update();Now it becomes:
- Fast
- Controlled
- Safe
But Wait — Don’t Overuse It :Higly dangerious
Here’s the mistake many developers make:
They start using setWorkflow(false) everywhere.
That’s just as dangerous.
Because now you are skipping important logic, like:
- Audit history
- Approval triggers
- Business validations
- Notifications
So the rule is simple:
Use it only when you intentionally want to bypass the system logic.
Pro Tip (Most People Miss This)
If you're inside a Before Business Rule, you often don’t need current.update() at all.
Just do:
current.priority = 1;ServiceNow will automatically save it.
No extra update needed. No risk. No loop.
Finaly please be careful when playing with current.update and setworkflow false, even if its a after BR, you never know what can break by using these, unless its broken and you jump into debug mode. haha,
Hope this helps, see ya next time.
