Sync Comments and Work Notes without Duplicates

[Saura Sambit]

In the ServiceNow ecosystem, we frequently encounter the requirement to synchronise journal field entries, such as Work Notes or Additional Comments, between related task records. The most straightforward approach is to use business rules. This method works well for unidirectional synchronisation. However, when synchronisation needs to be bidirectional, duplicate journal entries begin to appear due to recurring triggers of the business rules.

Over the years, various approaches have been employed to address this issue, including the creation of custom checkbox fields, setting workflows to false, and several others. While these methods are effective, they often introduce some form of technical debt. In this article, we will explore a straightforward solution for achieving bidirectional synchronisation. Our method will not involve creating custom fields or disabling notifications and other updates by setting workflows to false.

• Keep the below snippet in mind, we will be making use of this.

[code]<p DoNotCopy></p>[/code]

 

Requirement

When a Work Note is added to any Incident [incident] record,

• copy the Work Note to the parent incident.
• copy the Work Note to any child incidents.

 

Business rule configuration

1. Navigate to Business Rules table and proceed to create a new rule.
2. Set the values as follows -
   • Name - anything
   • Table - Incident [incident]
   • Advanced - true
   • When - before
   • Update - true
   • Filter Conditions - Work notes changes

       3. Under the 'Advanced' tab, the configuration should look something like below.

• Condition -

current['work_notes'].indexOf('DoNotCopy') == -1

• Script -

• Copyable version of the script can be found here.

 

How will this stop the recurring triggers?

In line 20 of the script, before copying the work_notes, we are adding a code snippet to it.

[code]<p DoNotCopy></p>[/code]

Since it is an empty HTML block, the code snippet remains invisible when viewing the work notes directly, but it can be detected through code. Therefore, the condition field on the business rule will check for this snippet's existence and prevent the business rule from being re-triggered.

• Condition -

current['work_notes'].indexOf('DoNotCopy') == -1

Number of custom fields? Zero. setWorkflow(false)? Not needed.

Just keep adding a similar snippet and condition to the business rule whenever there is a need to copy journal entries automatically and there would be no duplicates.

The business rule can also run 'after' or 'async', we just have to access the journal fields like -

current.work_notes.getJournalEntry(1)

 

Next steps

Experiment by writing rules to copy journal entries across multiple tables, share among your peers.

[Priyanka_1994]

@Saura Sambit Thanks for sharing it. New thing to learn.

Regards,

Priyanka Salunke

[Shilpa451]

@Saura Sambit , We are facing the same issue in integration with Azure Devops. We have used REST message and scripted REST calls to make this integration. Work notes are getting duplicated. Can you help me how to avoid this? Thank you in advance.

[MuthyamSai]

Hi Saura Sambit

It's working fine parent to child and child to parent.

Is it possible for all child incidents under the same parent incident to view each other's work notes, and if so, how can this be implemented?

[Mohammed Daiyan]

Is this possible for CSM integration with Incident management, syncing the Case worknotes to INC worknotes and INC worknotes to case worknotes.
Also Case additional comments to INC add comments, and INC add comments to Case additional comments?

[dbook]

Having done something similar myself, whilst this approach can work I don't think it is the best approach. 

Wrong trigger surface. Running Before/Update on incident means you fire on any update where work_notes changed, but you still don’t know which journal row changed. Concurrent edits can race.

Author & audit. incGr['work_notes'] = ...; incGr.update() attributes the note to system and may not consistently behave like setJournalEntry() (which is the supported pattern for journals).

Synchronous updates. Doing cross-record updates in a Before rule increases contention and can surprise users if the outer transaction rolls back.

I would instead recommend the following approach:

Create a BR on sys_journal_field table.

Name: Copy Incident Work Notes to Parent/Children

• Table: sys_journal_field

• When: After

• Insert: true

• Advanced: true

• Condition (Advanced): (current.name == 'incident') && (current.element == 'work_notes') && (String(current.value).indexOf('[code]<p DoNotCopy></p>[/code]') == -1)

• Script

(function executeRule(current /* sys_journal_field */) {
  // current fields we rely on:
  // current.name         -> source table ('incident')
  // current.element      -> 'work_notes'
  // current.element_id   -> sys_id of the incident
  // current.value        -> the exact note just added

  var note = String(current.value);
  var srcInc = new GlideRecord('incident');
  if (!srcInc.get(current.element_id)) return;

  // Prepare stamped body (invisible HTML comment as marker)
  var stamped = note + '[code]<p DoNotCopy></p>[/code]';

  function addWorkNote(gr, text) {
    // Use supported journal API
    gr.work_notes.setJournalEntry(text);
    gr.update(); // async rule, so this is fine
  }

  // Copy to parent incident (if any)
  if (srcInc.parent && srcInc.parent.getRefRecord().getTableName() == 'incident') {
    var p = srcInc.parent.getRefRecord();
    addWorkNote(p, stamped);
  }

  // Copy to active child incidents
  var ch = new GlideRecord('incident');
  ch.addQuery('active', true);
  ch.addQuery('parent', srcInc.getUniqueValue());
  ch.query();
  while (ch.next()) {
    addWorkNote(ch, stamped);
  }
})(current);

Hey presto, we are done with the below benefits; 

• No duplicate loops: the target entries are stamped with [code]<p DoNotCopy></p>[/code]; when those insert, the BR condition short-circuits. - Thanks to  

  Saura Sambit! 

• Right granularity: you react to the single journal row that fired, not “whatever the latest is”. Thus preventing potential leaks of sensitive data if two work notes are entered at the same time. 

• Clear author/time: you copy the content, but the new entry is correctly logged as a system add; if you want to show provenance to fulfillers, append a small header like (from INC+srcInc.number+) before the invisible stamp.