Security Incident Response Task Changed(sir.task.changed) - trigger conditions and recipient mapping

SumiD
Tera Contributor

3 weeks ago

Hi Team,
 
I am investigating the OOB SIR notification "Security Incident Response Task Changed".
 

I found KB0859879 which states that the notification is processed through the "Notification for task" business rule on the sm_task table.

 

The KB references the method:
configProcessor.sendNotifications(current, previous, "sm.task.changed")

 
Based on this, I understand why I am not seeing a corresponding sir.task.changed event in Event Logs.
 
However, I am still trying to validate the following:
 
1. What specific updates trigger this notification?
   - Does any update to a Security Incident Response Task trigger it?
   - Or only specific field updates (for example Assigned To, Affected User, Requested By, State, etc.)?
 
2. In the notification recipient configuration:
   - What does "Event Creator" resolve to?
     (user who performed the update, task creator, assigned user, etc.)
 
   - What user is passed through "Event Param 2"?
 
3. Has anyone validated the actual recipient mapping for this OOB notification in recent releases?
 
Any documentation, KB, community references, or testing results would be appreciated.
 
Thank you.
0 Helpfuls
  • 629 Views
1 REPLY 1

kmohammed
Mega Guru

yesterday

You are right about why there is no event in the Event Log. sm.task.changed is not queued with gs.eventQueue, so you will not find a sir.task.changed record in sysevent. The Notification for task business rule on sm_task calls sendNotifications(current, previous, "sm.task.changed"), which evaluates the notification records for that event directly and hands the resulting mail to the notification engine. Check sys_email, not the Event Log, to see what was actually sent.

 

1. What triggers it: the business rule itself does not contain a fixed list of fields such as Assigned To or State. It runs on update to the task, and the real filter is the Condition on the Security Incident Response Task Changed notification record itself. If that notification has no condition, any update to the task will be evaluated for sending. If you only want it on specific field changes, that is where to add the condition, for example Assigned To changes or State changes, rather than changing the business rule.

 

2. Event Creator: this resolves to the user who performed the update, that is current.sys_updated_by at the time the business rule runs. It is not the task creator and not the assigned user, unless the same person also made the update.

 

Event Param 2: do not treat this as a fixed user. It is the second parameter the processor passes for that notification, and the reliable way to confirm it in your release is to open the notification record, look at Who will receive, and see which recipient row uses Event Param 2, then test it: update Assigned To on one task and State on another, and compare the recipients in sys_email. That test will show you the actual mapping for your instance, including whether a recipient is suppressed because it matches the user who made the update.

 

In short: trigger = task update plus the notification's own condition; Event Creator = updater; and Param 2 must be read from that notification record and verified in sys_email, because it is not a separate event you can trace in the Event Log.

0 Helpfuls