Duplicate Task SLA created after Incident Reopen when Retroactive Start is enabled (PROD only)

artigpandey
Mega Contributor

3 weeks ago

Hi Team,

I am investigating a duplicate Task SLA issue in our PROD environment and would appreciate any guidance.

SLA Configuration

SLA Definition: TCS MIS Medium Resolution (2 Days)

Start Conditions

  • Priority = Medium
  • Assignment Group.Group Type = TCS MHS
  • Active = true

Retroactive Start

  • Enabled
  • Set Start To = Assign Time to TCS

Stop Condition

  • State = Closed

Reset Condition

  • None configured

Investigation Performed

Business Rule populating Assign Time to TCS

A custom Business Rule populates the field "Assign Time to TCS" only when:

  • Assignment Group Type = TCS MHS
  • Assign Time to TCS is empty
    Script
    if(current.assignment_group.u_rs_group_type=='2')
        current.u_damenassign_tcs = gs.nowDateTime();
    This field is populated only once and is not cleared later.

    Observed Behavior

    First Task SLA

    • Created By: asin06
    • Created On: 2026-06-30 16:28:33
    • Start Time: 2026-06-30 16:28:31
    • Completed: 2026-06-30 16:30:28

    Incident Update

    Audit history shows:

    • Time: 2026-06-30 16:30:45
    • Incident State: Resolved → In Progress
    • Reopen Count incremented
    • Updated by integration user

    Second Task SLA

    • Created By: TCS.dellBoomi
    • Created On: 2026-06-30 16:30:46
    • Start Time: 2026-06-30 16:28:31
    • Completed: 2026-06-30 16:34:17

    Because Retroactive Start is enabled, both SLA records receive the same Start Time based on the "Assign Time to TCS" field.

    Additional Findings

    The first Task SLA was created at 16:28:33 and completed at 16:30:28. The incident was reopened at 16:30:45, and a second Task SLA was created at 16:30:46. This timing suggests a possible relationship between the reopen event and the creation of the second Task SLA.

     

    • Only one active SLA Definition exists.
    • Reset Condition is empty.
    • Stop Condition is State = Closed.
    • DEV and TEST environments do not reproduce the issue.
    • Issue occurs only in PROD.
    • Duplicate SLA is consistently created immediately after the reopen update.
    • We could not find any custom Business Rule directly creating Task SLA records.

      Could the Incident Reopen event be causing the SLA engine to re-evaluate the Start Conditions and create a new Task SLA despite no Reset Condition being configured?
0 Helpfuls
  • 640 Views
2 REPLIES 2

Vikram Reddy
Tera Guru

3 weeks ago

Hi @artigpandey,

 

This is the SLA engine doing exactly what it is built to do, not a Reset Condition gap. Once a task_sla record for a definition reaches the terminal Completed stage, that record is done for good, it never reactivates. If the Start Condition on the definition is still true (or becomes true again) on a later update, and there is no longer an active task_sla attached for that definition, the engine creates a fresh one. Reset Condition only matters while an SLA is still active, it cancels that active instance and spins up a new one, so an empty Reset Condition does nothing here: by the time your reopen update fires, the first record has already gone terminal, and Reset Condition never gets a chance to intervene.

That also explains why both records show the identical Start Time. With Retroactive start enabled and Set Start To pointed at Assign Time to TCS, every task_sla created off this definition, first or second, backdates its start to whatever value sits in u_damenassign_tcs at that moment. Your custom Business Rule populates that field once and never clears it, so the second SLA just inherits the same old timestamp instead of getting a fresh start based on the reopen. It looks like a duplicate of the same interval, but it is really two separate task_sla lifecycles both anchored to one stale timestamp.

The real question is why the first record went Completed at 16:30:28, seventeen seconds before the reopen audit entry, when your Stop Condition is only State = Closed and the visible transition is Resolved to In Progress. That is your PROD-only tell. Pull sys_audit for that window and check whether state briefly passed through Closed, or another value matching your Stop Condition, inside the same integration transaction before landing on In Progress. Multiple update operations against one task record in quick succession from an integration is a documented trigger for this exact symptom: ServiceNow has a Known Error, KB0541990, "Multiple close/insert/update operations on a task record can lead to duplicate SLAs." That would also explain why DEV and TEST never reproduce it, they are not carrying the same live, high-frequency TCS.dellB​oomi traffic pattern as PROD.

To close this out:

  • Confirm in sys_audit whether the state actually touched Closed (or your exact Stop Condition value) between 16:28:33 and 16:30:45, not just Resolved to In Progress.
  • Ask your integration team whether TCS.dellB​oomi is firing more than one update against the same incident in that window, and log a case against KB0541990 if so.
  • Redesign the SLA to use a Pause Condition (state = Resolved) and a matching Resume Condition instead of relying only on Stop = Closed. A paused task_sla stays the same active record and resumes on reopen, so it never goes terminal and never leaves room for a second record.
  • As a belt and suspenders guard, add incident.reopen_count is 0 to the Start Condition so a reopened incident that already had this SLA attached once cannot re-trigger the same definition a second time.

References

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls

artigpandey
Mega Contributor

3 weeks ago

Hi Vikram,

Thank you for the detailed explanation.

Your explanation aligns with the evidence gathered during our investigation. We observed that the first Task SLA was completed, the incident was subsequently reopened by the integration user, and a second Task SLA was created immediately afterward. Since Retroactive Start is enabled and uses the "Assign Time to TCS" field, both Task SLA records inherited the same start timestamp, which initially made them appear as duplicates.

I will further investigate the audit history around the completion timestamp to verify whether the incident briefly transitioned through a state satisfying the Stop Condition before the reopen update.

I will also review the integration updates and discuss with the integration team whether multiple updates are being performed on the same incident within a short timeframe, as mentioned in KB0541990.

One follow-up question:

If the business requirement is to maintain a single continuous SLA even when the incident is reopened, would you recommend redesigning the SLA using Pause/Resume behavior (e.g., Pause on Resolved and Resume on Reopen) as the preferred long-term solution, rather than introducing additional Start Condition checks such as reopen_count = 0?

Thank you for your assistance.

0 Helpfuls