Preventing Checklist Updates from Flooding Worknotes

ServiceNow's checklist feature is a valuable tool for standardizing processes and ensuring tasks are completed. However, users often encounter a situation where every update to a checklist item generates a worknote on the associated record, such as an incident. While worknotes are essential for tracking activities, the sheer volume created by checklist interactions can lead to notification overload, making it difficult to focus on important updates. If you're experiencing this issue and looking for ways to manage these notifications effectively, you've come to the right place. This article will explore proven methods to prevent checklist updates from triggering excessive worknote notifications in your ServiceNow instance.

Solutions

The core of the problem lies in the default behavior of ServiceNow, where any change to a checklist item (creation, deletion, completion, etc.) automatically adds a corresponding entry to the worknotes field of the parent record. This, in turn, can trigger any notifications configured to fire upon worknote updates, leading to a flood of emails or alerts that might not be relevant to the core issue being addressed.

Here are a couple of effective strategies to address this and regain control over your notifications:

Solution 1: Implementing a Custom Condition on Your Worknotes Notification

One robust approach is to modify the condition of your worknotes notification to ignore updates originating from checklist activities. This method allows the worknotes to still be recorded for audit purposes while preventing unwanted notifications. Here's how you can achieve this:

1. Identify the Worknotes Notification: Navigate to System Notification > Email > Notifications and search for the notification that is being triggered by worknote updates on your target table (e.g., Incident).

2. Access Advanced Conditions: Open the notification record. You might see a simple condition builder. To implement a more sophisticated check, you'll need to use the "Advanced condition" field. If it's not visible, you might need to clear any existing conditions in the basic condition builder.

3. Add a Scripted Condition: In the "Advanced condition" field, paste the following script:

JavaScript

var notes = current.work_notes.getJournalEntry(1);
if (current.work_notes.changes()){
    if ((notes.indexOf('Checklist item:') > -1) || (notes.indexOf('Checklist created') > -1) || (notes.indexOf('Checklist deleted') > -1)) {
        answer = false;
    } else {
        answer = true;
    }
} else {
    answer = true;
}

-   **Explanation:** This script retrieves the latest worknote entry. It then checks if the worknote content contains specific keywords like "Checklist item:", "Checklist created", or "Checklist deleted". If any of these phrases are found, the script sets `answer` to `false`, effectively preventing the notification from being sent. Otherwise, `answer` is set to `true`, allowing the notification to proceed for other worknote updates.

4. Save the Notification: Once you've added the script, save the notification record.

This solution provides a targeted way to filter out notifications specifically related to checklist updates while ensuring that other important worknote entries still trigger notifications as intended.

Solution 2: Modifying the Business Rule Responsible for Adding Checklist Worknotes

Another effective method involves directly modifying the Business Rule that automatically adds worknotes when checklist items are created, updated, or deleted. By making a small change to this rule, you can prevent the notification engine from processing these specific worknote updates.

1. Locate the Business Rule: Navigate to System Definition > Business Rules and search for the Business Rule named "Add worknote for checklist item CRUD". Ensure the table is set to Checklist Item [checklist_item].

2. Open the Business Rule: Open the record for this Business Rule.

3. Modify the Script: In the "Script" section, locate the line that updates the worknotes field (it typically looks like grTask.work_notes = worknote;). Immediately after this line, add the following line of code:

JavaScript

grTask.setUseEngines(false);

-   **Explanation:** The `setUseEngines(false);` method prevents the notification engine (and other engines) from running when this specific update to the `grTask` record occurs. In this context, it effectively stops any worknote notifications triggered by this Business Rule.

4. Save the Business Rule: Save the modified Business Rule.

This approach offers a more direct way to control the notifications at the source of the worknote creation for checklist items.

Considering Alternatives

While the above solutions are effective, you might also consider alternative approaches depending on your specific requirements:

• Creating a Separate "Checklist History" Field: As suggested in the community, you could create a new field to store the history of checklist updates instead of relying on worknotes. This would require modifying the Business Rule to write to this new field instead of worknotes. However, this might involve more extensive customization.

• Utilizing a Third-Party Checklist Application: Some applications available on the ServiceNow Store, like the one mentioned in the community, offer checklist functionalities that do not automatically update worknotes. This might be a viable option if you need more advanced checklist features and want to avoid worknote notifications altogether.

Conclusion

Managing notifications effectively is crucial for maintaining a productive ServiceNow environment. When checklist updates lead to an overwhelming number of worknote notifications, implementing a custom condition on your notification or modifying the responsible Business Rule provides effective ways to regain control. By carefully choosing the solution that best aligns with your auditing needs and notification preferences, you can ensure that your team receives relevant updates without being inundated by unnecessary alerts. Take the next step by exploring these methods in your ServiceNow instance and tailoring them to your specific use case.