Business Rule firing twice on RITM update when in On Hold state

[P Seth]

I have the following setup on the sc_req_item table (RITM):

1. Workflow

   • If the On Hold Target Date passes → a comment is added to the RITM (via Set Value in Workflow) and the state is changed to Work in Progress (WIP).

2. Business Rule (Before)

   • When a user updates the RITM while it is in On Hold state, the BR sets the state to WIP.

3. Business Rule (After) → “Comment update”

   • Runs on insert and update.

   • Condition:

     current.assigned_to != gs.getUserID() && current.comments.changes()

   • If the condition is true, it triggers an event (XXXX) which sends a notification to the assignee.

---

The Issue:

• Everything works fine in general.

• Problem occurs when:

  • The RITM is in On Hold state and either:

    1. A user updates the RITM, or

    2. The Pending Target Date passes and the workflow sets comments + state.

In these cases, the “Comment update” BR runs twice for the same record update, and two notification emails are sent to the assignee.

[Rafael Batistot · Accepted solution]

Hi @P Seth 

May you consider those steps

• Scenario A – User updates RITM while On Hold
  
• User submits an update.
• Your Before BR changes the state to WIP.
• Because state changed, that counts as an update → triggers your After BR.
• At the same time, the user’s comment field update also triggers the After BR.
• So, you get 2 notifications.
• Scenario B – Workflow sets Comment + State
  
• Workflow “Set Value” changes two fields at once (state + comments).
• ServiceNow processes these as separate field updates in the same transaction.
• Your “Comment update” After BR condition sees the comments field changing → but the state update also causes the same rule to be evaluated again in the same cycle.

You want to make sure the “Comment update” BR only fires once per logical update.

Check current.operation()  and suppress duplicates

Add a guard so it only runs on comment changes when that’s the actual user change:

// After BR condition
current.assigned_to != gs.getUserID() &&
current.comments.changes() &&
!current.state.changes()

This way, if the only reason it’s firing is because state also changed, it won’t double trigger.

[RaghavSh]

There should be some pther BR as well which is copying comments from RITM to sc_task and vice versa?

If yes you need to add user/ addigned to conditions on those BRs as well/