Duplicate Task SLA records created for same Incident and SLA Definition causing incorrect SLA breach

MuditR999
Tera Contributor

3 weeks ago

Hi Everyone,
 
We are currently investigating an issue where multiple Task SLA records are being attached to the same Incident for the same SLA Definition.
 
Examples observed:
- Some incidents have 2 identical Task SLA records attached.
- Some incidents have 3 identical Task SLA records attached.
- All Task SLA records reference the same SLA Definition.
- The Task SLA records are created at the same timestamp and have the same start time.
 
What we are seeing is that only one of the Task SLA records behaves correctly when the incident enters a paused state.
 
For the valid Task SLA:
- pause_duration and business_pause_duration are populated
- planned end time is recalculated correctly
- SLA does not breach
 
For the duplicate Task SLA records:
- pause_duration and business_pause_duration remain empty
- actual elapsed time continues to increase
- planned end time is not adjusted
- SLA breaches incorrectly
 
As a result, the same incident can have one non-breached Task SLA and one or more breached Task SLAs for the exact same SLA Definition.

Based on the incidents reviewed so far, we believe that if the duplicate Task SLA creation issue is identified and resolved, the pause calculation issue may also be resolved as a result. However, we have not yet confirmed whether the pause behavior is solely a consequence of the duplicate SLA creation or a separate underlying issue.

Has anyone encountered similar behavior where:
1. Multiple Task SLA records are created for the same Incident and SLA Definition?
2. Only one Task SLA processes pause calculations correctly while duplicate records continue running?
3. Duplicate Task SLA records subsequently breach even though the incident was in a paused state?
 
We have raised a HI case with ServiceNow and would appreciate any insights from the community regarding similar experiences, known causes, defects, KB articles, or recommended troubleshooting approaches for this behavior.
 
Thank you.
0 Helpfuls
  • 397 Views
2 REPLIES 2

MuditR999
Tera Contributor

Tuesday

Hi @Vishal Jaswal 

Thank you for your reply, and I apologize for my delayed response.

I have reviewed the posts and examined the existing before query business rules on the task_sla table which we have none. Although I found a total of five before rules, four of which are disabled, and one that is active. The active rule has a condition that triggers when the Business Elapsed time changes AND the SLA is either P1 or P2. However, we are encountering issues with P3 and P4 as well when they are being attached.

Additionally, I checked the configuration of the SLA definition for one of the most frequently attached SLAs, specifically the P4 SLA. It appears to be correctly configured, except that the Retroactive start option is unchecked. Please refer to the attached screenshot.


Screenshot 2026-11-03 233047.png

 



We also have a case open with HI support to resolve this issue, but they are still investigating the root cause. A few days ago, they identified two after business rules—one on the incident table and another on the task_sla table—that utilize current.update(). These may be contributing to the problem. I attempted to deactivate these business rules individually and together while testing in the Dev instance, but the issue remains unresolved.

They have now requested that we enable SLA debugging on the Dev instance, and I have provided them with examples after reproducing the issue, which is still under investigation.

Any additional assistance would be greatly appreciated.


Regards,
Mudit

 

0 Helpfuls