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?

[Tanushree Maiti]

Hi @SaipriyankaG 

Refer KB: KB2923037 Duplicate Email Notifications Are Generated for an update on a table 

Cause

The issue was caused by a current.update() call within a Custom Business Rule. This forced an additional database save of the same record immediately after the initial insert, effectively writing the record twice in the same transaction.

This double-save triggers the events twice, generating two sets of email notifications. The OOB Ignore Duplicates rule catches the second set and marks them "send-ignored", but the first set is already sent, resulting in receiving duplicate emails.

 

 

Resolution

Modify the custom Business Rule as follows:

 Step 1: Change the Business Rule timing and order

• Set When: Before
• Set Order: 999,999

Changing the rule to Before ensures the Business Rule logic runs within the same transaction as the record insert, preventing an additional save from being triggered. This ensures that, the events fire only once, eliminating duplicate email notifications. Setting the order to 999,999 places this rule last in the Before rule execution sequence, avoiding unintended side effects on other Before rules.

Step 2: Remove (current.update())

current.update() forces an additional save of the same record, which re-triggers Business Rules and generates duplicate events. Removing it eliminates the second save cycle entirely.

[dellyou088]

Troubleshooting steps:

1.Open the mail and check , from where it is getting triggered if it is triggering from event check for event log.

2.Go to studio and search for that event in the search bar to find from where it is configured or written.

3.If it is from any flow check the flow execution history to find.

More information is appreciated.

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards

[Suryansh Verma]

@SaipriyankaG 

Recommended troubleshooting

First determine whether the duplication occurs at the event level or the notification level.

1. Check the Event Log

Navigate to:

System Policy → Events → Event Log

Filter by: Name = <your SLA breach event> Created = <timestamp>

Compare:

• Event name
• Instance
• Table
• Parm 1 and Parm 2
• Created timestamp
• Event sys_id

ServiceNow uses records in the Event [sysevent] table to queue events for processing.

Interpretation

• Two event records: The Flow or another process generated the event twice.
• One event record: The duplication is occurring in the notification configuration.
• Two events with different Task SLA instances: Two separate SLAs may have breached for the same task.

2. Check the Email Log

Navigate to:

System Logs → Emails

Open both generated emails and compare:

• Notification
• Source table
• Target record
• Recipients
• Subject
• Created timestamp
• Related event

Every generated notification is recorded in the Email [sys_email] table.

If one event produces two emails, check for:

• Two active notifications listening to the same event
• One OOTB notification and one custom notification
• Duplicate recipients through User, Group and scripted recipient logic
• A second notification configured directly on the table update

Most likely cause

The Flow may be running more than once because its trigger condition remains true after the SLA breaches.

For example, this condition can execute repeatedly: Actual elapsed percentage is greater than or equal to 100

The Task SLA record may continue to be updated after it reaches 100%. If the Flow trigger is configured as For every update or For each unique change, each subsequent update can start another Flow context. ServiceNow documents that “For every update” starts a Flow every time the record is updated, while “For each unique change” can also produce multiple executions and recursion.

Check:

Flow Designer → Executions

Search using the affected Task SLA sys_id. If two Flow contexts exist for the same Task SLA and timestamp, the Flow trigger is the source.

[VJ_Srivastava]

Hello SaipriyankaG,

From a platform architecture perspective, anomalous duplication of outbound communications often highlights a race condition or overlapping logic within the platform's event processing layer.

Looking at your system logs, these are SLA breach alerts. When configuring SLA-driven logic, relying on disparate legacy Business Rules or overlapping workflow triggers can frequently create these duplicate transaction contexts during state changes.

To resolve this permanently and maintain platform scalability, I recommend auditing the event architecture specifically for your SLA processes. Transitioning legacy SLA workflows into a centralized, idempotent Flow Designer architecture ensures that state changes only emit a single, distinct event payload. Standardizing your triggers now prevents your SMTP queues from being unnecessarily taxed and ensures clean, predictable outbound traffic as your enterprise transaction volume scales.

[Tanushri]

Hi SaipriyankaG,

Great catch on identifying this! While this might seem like a minor technical glitch on the backend, duplicate notifications can severely impact operational efficiency and end-user experience.

When support agents or stakeholders receive spam-like duplicate emails—especially for critical alerts like the SLA breaches shown in your logs—alert fatigue sets in very quickly. Users start habitually ignoring ServiceNow emails altogether, which completely defeats the purpose of having automated, time-sensitive SLA warnings in the first place.

Resolving this quickly ensures your platform's communication channels remain trusted and actionable. I highly suggest having your development team streamline the underlying triggers to ensure clean, singular alerts. Protecting your users' inboxes is a crucial part of maintaining high user adoption and confidence in the platform's reliability.