✅ Why the “sn_si.TaskAssigned” Notification Isn’t Triggering on Security Incident Task Updates
When a notification tied to the event `sn_si.TaskAssigned` does not trigger after updates to a Security Incident Task (SIT) (such as state, priority, or assigned_to changes), it typically means the event is never being generated during those updates. Notifications in ServiceNow that depend on events only fire when the corresponding gs.eventQueue() or gs.eventQueueScheduled() call is executed — not automatically on record changes.
--------------------------------------------------------------------
🔍 Root Cause
--------------------------------------------------------------------
The `sn_si.TaskAssigned` event is not an “automatic” system event — it must be explicitly fired by a Business Rule or Script Action.
If you are changing Assigned To, State, or Priority, but no Business Rule exists to call `gs.eventQueue('sn_si.TaskAssigned', current, ...)`, the notification won’t trigger.
--------------------------------------------------------------------
🧩 How to Fix It
--------------------------------------------------------------------
Option 1 – Create or Update the Business Rule to Fire the Event
1. Navigate to System Policy → Business Rules
2. Search for an existing rule related to Security Incident Task assignment.
3. If not found, create a new Business Rule on table `sn_si_task`:
- When to run: After update
- Condition:
```javascript
(current.assigned_to.changes() || current.state.changes() || current.priority.changes())
```
- Script:
```javascript
(function executeRule(current, previous /*null when async*/) {
gs.eventQueue('sn_si.TaskAssigned', current, current.assigned_to, gs.getUserID());
})(current, previous);
```
4. Save and test again — when the assigned user, state, or priority changes, the event will be logged in System Logs → Events (sysevent).
Option 2 – Trigger the Notification Using “When to Send” Conditions
If you don’t want to rely on custom events, you can modify your notification to trigger directly on record updates:
1. Go to System Notification → Email → Notifications
2. Open your existing Security Incident Task Change notification.
3. Change:
- “When to Send” → Record Updated
- Add conditions:
- State changes OR Priority changes OR Assigned_to changes
4. Ensure “Who will receive” is properly configured (e.g., Assigned to, Watch list, or a specific group).
--------------------------------------------------------------------
✅ Validation Steps
--------------------------------------------------------------------
1. Make an update to an SIT record’s state, priority, or assigned_to.
2. Go to: System Logs → Events
- Verify that the event `sn_si.TaskAssigned` is generated.
3. Check: System Mailboxes → Outbound → Sent
- Confirm the notification email is sent.
--------------------------------------------------------------------
⚙️ Summary
--------------------------------------------------------------------
| Cause | Fix |
|-------|-----|
| Event not fired on record update | Add Business Rule with `gs.eventQueue('sn_si.TaskAssigned')` |
| Notification configured only for events | Switch to record-based “When to Send” trigger |
| No event logged in sysevent table | Confirm event is fired correctly |
| Notification recipients misconfigured | Ensure proper roles/fields in “Who will receive” |
✅ Best Practice:
If you want more granular control (e.g., different notifications for different SIT states), use Business Rules + custom events.
For simpler scenarios, prefer record-based notifications — they’re easier to maintain and debug.
