Notification Triggering Twice with the Same Timestamp

[SaipriyankaG]

We are observing an issue where the notification is being triggered twice with the exact same timestamp. Has anyone encountered a similar issue or can suggest possible causes and troubleshooting steps?

[NehaG8791370651]

Hi SaipriyankaG,

When I see exact timestamp duplicates in the sys_email table—like the "2026-07-17 09:10:22" SLA breach emails in your screenshot—it almost always points to the event queue rather than the notification engine itself.

Since your subject line mentions a Breached SLA, here are the most practical troubleshooting steps to find the root cause:

1. Check the sysevent Table: Navigate to the event logs for that exact timestamp. Are there two identical events fired? If yes, the issue is with what triggers the event, not the notification record.

2. Multiple SLAs: Check if there are multiple SLAs attached to that specific incident (INC0947...). If two different SLAs on the same ticket breached at the exact same second, the SLA workflow will fire the breach event twice.

3. Business Rule Loops: Look for any custom Business Rules on the task_sla or incident table that might be using current.update() improperly, causing a recursive update that fires the notification condition twice.

4. Notification Weight: If the events aren't duplicated, check if you have two distinct notifications configured with the same conditions and a Weight of 0. Give them appropriate weights so the system knows to only process the one with the highest value.

[NehaG8791370651]

Hi Alon,

This is a great question, as the data structure for Service Catalog variables can be a bit tricky to navigate initially. The values aren't stored in a single flat table; instead, ServiceNow uses a relational model depending on the type of variable set.

Here is the breakdown of where to find this data:

• Standard Variable Sets: The actual values a user submits are stored in the sc_item_option table. To link those specific values to the Requested Item (RITM) they belong to, you have to query the Many-to-Many table: sc_item_option_mtom.

• Multi-Row Variable Sets (MRVS): If your variable set is multi-row, the architecture is different. The data is stored in the sc_multi_row_question_answer table.

If you are scripting (like in a Business Rule or Script Include), the best practice is to avoid querying these tables directly. Instead, always use the current.variables.your_variable_name object to access the values dynamically!