Comments are populating multiple times on RITM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-28-2024 06:47 AM
I have written an script include which is called by an async insert business rule which basically calls the api after that we receive a Ref id from response which we update in the worknotes from there another after update business rule is written which updates the RITM and Request worknotes for Request it is working fine but for RITM the Ref ID populating two times. This happens only for first time
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-28-2024 07:56 AM
I hope your 1st BR is only Async Insert and Not Update
Did you check Update checkbox is unchecked?
your 1st BR is triggered again and hence adding 2 times.
ensure the BR condition for API is configured in such way that it triggers only once
OR
when 2nd BR runs and updates the RITM use setWorkflow(false) to avoid triggering the 1st BR
If my response helped please mark it correct and close the thread so that it benefits future readers.
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-29-2024 06:43 PM
Hope you are doing good.
Did my reply answer your question?
If my response helped please mark it correct and close the thread so that it benefits future readers.
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-29-2024 09:49 PM
The issue of the Ref ID being populated twice in the RITM worknotes on the first update can be caused by multiple triggers from your after update business rule. This often happens when the update to the work_notes field is treated as a trigger for the business rule, which then executes again, leading to duplicate entries. To resolve this, you can add a condition in your after update business rule to prevent it from firing multiple times during the same transaction. By checking if the work_notes field is being updated programmatically and using flags to ensure the rule only runs once, you can avoid this issue. Here's an example of how to implement this:
if (current.work_notes.changes() && !gs.isInteractive()) {
// Avoid duplicate updates
if (gs.getSession().getProperty('ritm_worknotes_updated') == 'true') {
gs.log('Skipping duplicate update for RITM: ' + current.number, 'RITM Update Debug');
return;
}
gs.getSession().setProperty('ritm_worknotes_updated', 'true');
// Update RITM and Request work notes
var ritm = new GlideRecord('sc_req_item');
if (ritm.get(current.sys_id)) {
ritm.work_notes = 'Ref ID: ' + current.u_ref_id;
ritm.update();
}
var req = new GlideRecord('sc_request');
if (req.get(current.request)) {
req.work_notes = 'Ref ID: ' + current.u_ref_id;
req.update();
}
gs.log('Updated work notes for RITM: ' + current.number + ' and Request: ' + req.number, 'RITM Update Debug');
}
In this script, we check if the work_notes field has been changed and whether the update was triggered by a script (using gs.isInteractive()). We also use a session property (ritm_worknotes_updated) to flag whether the business rule has already run for the current transaction. This prevents the business rule from executing multiple times and avoids the duplication of the Ref ID. After the updates are completed, we log the changes for debugging purposes.