(Activity Stream Compose) Include updated "Watch list" users in comment notifications

[Daniel_san]

Hi all,

1. When a user modifies the Watch list (or Work notes list) field.
2. and then clicks "Post comment" (or "Post work note") without explicitly saving the record first.
3. The notification triggered by the journal entry does not include the newly added/removed users.

The notifications are triggered by events generated from Business Rules (against incident table) that checks journal changes, with logic similar to:

if (current.operation() !== 'insert' && current.comments.changes())

What would be the simplest and most efficient way to ensure that changes made to the watch list and work notes list are included in the notification recipients, even if the record has not been saved yet?

Thanks!

[Mark Manders]

None. The updated list needs to be on the server for the notification to get it. From a ServiceNow point of view, that comment is posted to the previous version of the incident (the one saved server side). So your system does see the change of the comments, but not the change to the list fields. 

You could add a condition of 'watch list changes OR work notes list changes' and then send it to the new users as well, but that will end up with the old users not getting it if the comments are saved instead of posted at the same time as the list changed.

[Daniel_san]

Thank you @Mark Manders. 

Conceptually, the good idea would be to modify the action triggered when clicking the “Post Comment” button so that, if it detects changes in the watch list or work notes fields, it saves those changes before adding the comment. However, I haven’t been able to locate a specific action where this behavior is configured, and I’m still not fully comfortable working with UI Builder.

Even though it’s not a critical issue, it does seem quite obvious that this would be the correct and expected behavior.

As a less ideal workaround, I’ll add some client scripts to display warnings reminding users that, if they modify either of those two fields, they need to click “Save” on the record.

 g_form.showFieldMsg(
      'watch_list',
      'SAVE the record before posting new comments or work notes.',
      'error',
      false
   );​

[Mark Manders]

The 'post' button should not be used when changing those fields. That's the main issue. 'POST' was introduced to update comments/work notes without saving the entire record to the database. That you expect other fields to also be saved to the database without saving the record is where the logic goes wrong. It wouldn't really be a good thing to just have everything saved automatically. 'post' is the exception, so the alert should read 'if you have changed the watch list, work notes list, assigned to or any other field that is holding users and you want this comment or work note to be send to them as well, don't use 'post', but save/update the record'.

[Daniel_san]

Thanks again for your feedback @Mark Manders 

I understand your point, and I agree that technically Post Comment / Post Work Note is working as designed.

My concern is more from a user perspective. I find the difference between SAVE and POST quite confusing in this scenario.

• From an agent's point of view, if they modify the Watch list, Work notes list (or other fields such as assigned_to or caller_id) and then add a comment/work note, it is natural to expect that the notification generated from that action reflects the current state of the record they are seeing.
• I understand that automatically saving the whole record could have side effects, but from a usability perspective this behavior can be misleading, especially when the journal entry triggers notifications based on a previous version of the record.

For now, I will handle this with client-side warnings on the relevant fields that agents can modify in our case, making them aware that they need to save the record first if they want those changes to be considered. It still feels a bit counterintuitive from a user experience perspective, but I understand the reasoning behind the current behavior.

Thanks again for your input.