one Busines rule triggering another.

[AnkushH]

I have one business rule which is calling a script include inside it and the trigger conditions are After insert Update and few conditions but when it triggers and calls script include to creates incident in third party applications but when it triggers and calls script include and it is triggering update business rule as well.
I have used current.update() in script include to update work notes if anything fails during the transaction.
I dont know how and why. Can i use something else instead of current.update()?

[Community Alums]

Hello @AnkushH,

Yes, that behavior is expected. When you use current.update() inside your Script Include, it commits an update to the same record, which in turn triggers any “After Update” Business Rules on that table again causing a loop or unwanted re-execution.

To avoid that, use current.setWorkflow(false) before the update as shown below:
current.setWorkflow(false);
current.update();

If my response helped, please mark it as the accepted solution so others can benefit as well.

[MaxMixali]

ServiceNow – Avoiding Recursive Business Rule Triggers When Updating Work Notes

Problem
You have an AFTER Business Rule (BR) that calls a Script Include (SI) to create an incident in a third‑party app. When errors occur, your SI does:
current.update(); // to add work notes
This extra update re‑triggers the same AFTER BR (and other BRs), causing recursion/unwanted executions.

Why it happens
- Any call to current.update() (or GR.update()) fires the full update lifecycle again (Before/After BRs, Flows, Notifications, etc.).
- Doing this inside an AFTER BR is especially risky: your rule already saved the record; a second save will re‑enter the BR unless prevented.

Recommended patterns (use one)
1) Prefer BEFORE BR: set work notes before the first save
- Move the logic that appends work notes into a BEFORE BR (or set a flag/message in memory and write before save).
- Example:
current.work_notes = 'Third‑party creation failed: ' + errorMsg; // in BEFORE Update
- Journal fields can be set in BEFORE rules and will append on save.

2) If you must update the record after save, disable engines for that update
- Create a new GlideRecord on the same table and use:
gr.setWorkflow(false); // skip BRs & workflows
gr.setUseEngines(false); // skip Flow/Approvals/Notifications engines
gr.update(); // does not trigger your BR again
- Example:
var gr = new GlideRecord(current.getTableName());
if (gr.get(current.getUniqueValue())) {
gr.setWorkflow(false);
gr.setUseEngines(false);
gr.work_notes = 'Third‑party creation failed: ' + errorMsg;
gr.update();
}

3) Write directly to the journal without updating the task record
- Use GlideSysJournalEntry to append a work_note without firing BRs:
var je = new GlideSysJournalEntry();
je.setTableName(current.getTableName()); // e.g., 'incident'
je.setDocumentKey(current.getUniqueValue());
je.setElement('work_notes');
je.setJournalEntry('Third‑party creation failed: ' + errorMsg);
je.insert(); // no record update lifecycle

4) Use events (decouple side effects)
- In your AFTER BR, queue an event with the needed info:
gs.eventQueue('x.app.thirdparty.failure', current, errorMsg, '');
- Handle it in an Event BR or Script Action that uses pattern #2 or #3 to log work notes without recursion.

5) Asynchronous worker or Outbound REST “Async” pattern
- Move the outbound call into an Async BR / Scripted REST / Flow Action that returns control quickly.
- On failure, log using #2 or #3.

What NOT to do
- Don’t call current.update() inside an AFTER BR (will re‑trigger).
- Avoid updateAsync() for this case — it still triggers BRs.
- Don’t rely on gs.addInfoMessage for audit logging; it’s UI‑only.

Quick decision guide
- Need to append work notes but avoid any re‑trigger? → Use GlideSysJournalEntry (pattern #3).
- Need to change other fields quietly? → Use setWorkflow(false) + setUseEngines(false) on a fresh GlideRecord (pattern #2).
- Can you add notes before save? → Move to BEFORE BR (pattern #1).

Minimal examples
A) BEFORE BR append:
current.work_notes = 'Failed to create ticket in 3rd‑party: ' + errorMsg;

B) Silent update from Script Include:
var gr = new GlideRecord(current.getTableName());
if (gr.get(current.getUniqueValue())) {
gr.setWorkflow(false);
gr.setUseEngines(false);
gr.work_notes = 'Failed to create ticket in 3rd‑party: ' + errorMsg;
gr.update();
}

C) Direct journal write:
var je = new GlideSysJournalEntry();
je.setTableName('incident');
je.setDocumentKey(current.sys_id);
je.setElement('work_notes');
je.setJournalEntry('Failed to create ticket in 3rd‑party: ' + errorMsg);
je.insert();

TL;DR
- current.update() inside AFTER rules causes recursion.
- Either write notes in BEFORE, or perform a “silent” update with setWorkflow(false)/setUseEngines(false), or write directly to the journal via GlideSysJournalEntry.