Additional comments notification from system update

[BenjaminY]

Hello,

I am tasked with setting up notification when approver has sent a comment on the additional comments field. Within our flow the system also updates this field which is causing the additional comments notification send unnecessary notifications. I have tried to filter our phrases in script but that is not working. Please advise

Notification Script:

var recipients = [];

var commenter = current.sys_updated_by + '';

var requestor = current.requested_by + '';

var systemUserToIgnore = ['system', 'flow.engine'];

var isSystemGenerated = systemUserToIgnore.indexOf(commenter) > -1 || !gs.getSession().isInteractive();

var blockPhrases = [

    'Your request has been approved by the', 'Your request has been rejected by the', 'Your request is now awaiting the', 'Your request is now awaiting the '

];

var commentText = current.comments.toString() || '';

var isBlockedComment = blockedPhrases.some(function(phrase) {

    return commentTest.indexOf(phrase) > -1;

});

if (

    commenter != current.requestor + '' && !isSystemGenerated && !isBlockedComment

) {

    recipients.push(requestor);

}

recipients;

[Mark Manders · Accepted solution]

What process is this? Are you sure the approver has the right to update the comments? Or is it the comment coming from the approval record that is copied to it?

If it is just the system, you can easily do this by filtering out the system user (if comments changes and updated_by IS NOT system).

[BenjaminY]

Thank you, did not think about this for some reason!

[Community Alums]

Hi @BenjaminY ,

I’ve implemented a similar requirement before, where we had to send a notification every 8 hours while the incident stayed in the “Awaiting for user information” state, and after the 5th notification the incident was auto-closed.

From my experience:

• Using Flow: technically possible, but it leads to thousands of active flow contexts if many incidents go into that state at the same time. Each context consumes system resources and can eventually block threads, which has a real performance impact—especially in busy environments.

• Business Rules: you could do it, but you’d end up writing relatively complex logic to schedule and cancel jobs based on state changes. It works, but maintenance can become tricky over time.

Best approach:
Use a Scheduled Job (Scheduled Script Execution). You can:

• Schedule a job (e.g., run every hour) that looks for incidents which have been in “Awaiting for user information” for more than 3 days and haven’t been updated.

• Send reminders as needed.

• If required, extend the logic to keep sending reminders or auto-close after certain criteria.

This keeps things lightweight:

• No need to track individual timers per record.

• No thousands of flow contexts.

• Easier to manage and debug: just one scheduled script that handles all records in scope.

Hope this helps! Let me know if you'd like an example script or design for the scheduled job.

[Mark Manders]

How does your scheduled job handle tickets that have had updates in work notes, system updates or other updates, even though they are still on the same status?