Get a first look at what's coming. The Developer Passport Australia Release Preview kicks off March 12. Dive in! 

Work Notes added on Parent Incident should remain only at Incident level.

Pavithra_Raghu
Tera Expert

I am seeking guidance on how to ensure that Work Notes entered on a parent Incident remain exclusively at the Incident level and are not automatically propagated or synchronized to any associated Incident Tasks. The objective is to preserve the existing Work Notes functionality for tasks while maintaining a strict separation between journal entries at the Incident and Incident Task levels. In other words, Work Notes added to the Incident should not appear on its tasks under any circumstance, and task-level Work Notes behavior should remain unaffected. What configuration or best practice approach is recommended in ServiceNow to achieve this separation?

13 REPLIES 13

Hello @Pavithra_Raghu ,

 

Sorry custom word were missing in above reply . Ensure is there any custom BR which enforcing that.

Hello @Pavithra_Raghu ,

 

 

I hope you are doing well . Does my response helps you ? 

 

If my response helps you then mark it as helpful and accept as solution. This will helps  further future queries.

Regards,

Aditya,

Technical Consultant

Hi @Aditya_hublikar ,

It appears that the Work Notes added on the Parent Incident were copied to the Incident Task due to an instance glitch, and the issue has now been resolved.

Appreciate your help!

Hello @Pavithra_Raghu ,

 

 Im glad your query is resolved ðŸ˜€ .

vaishali231
Tera Guru

hey @Pavithra_Raghu 

By default, Work Notes from a parent Incident do not flow down to Incident Tasks. So if you’re seeing that behavior, it’s definitely coming from a customization.

Most commonly, this happens because of:

A Business Rule copying fields

A Flow Designer flow triggered on Incident update

A Workflow activity

Some script referencing  current.work_notes

I would start by searching for work_notes in Business Rules and Flows related to incident and incident_task. In many cases, you’ll find something like:

task.work_notes = current.work_notes;

If that exists, the best fix is simply to remove that line or adjust the logic so only specific non-journal fields are copied.

I would strongly recommend not deleting entries from sys_journal_field as a workaround. That can create audit and upgrade issues. It’s much cleaner to stop the copy at the source instead of cleaning it up afterward.

If you really need a safeguard, you could add a before update Business Rule on incident_task to block non-interactive updates to work_notes, but ideally fixing the original automation is the right approach.

 

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

 

Regards

Vaishali Singh