When a task SLA is breached, a schedule job is triggered updating the information of the task SLA, setting the has_breached value among other things. In parallel, the SLA Percentage Timer activity within the workflow attached to the SLA is triggered and also updates the task SLA fields to have the most updated information when sending the notifications.

This results in concurrent modifications of the same record, which causes two updates with the same update number to occur. This also causes notifications to be sent twice if customer has a notification defined based on "has_breached changes to true" conditions.

Finally, this is visible only if task_sla records have audit enabled, which is not the case by default OOB.

Steps to Reproduce


  1. Enable Audit in the Task SLA table.

  2. Navigate to Service Level Management > SLA > SLA Definitions.

    For more information, see the product documentation topic Create an SLA definition.

  3. Create a new SLA definition with a Start Condition priority of 5 and set the Duration of the SLA definition to 2 mins for ease of testing/reproduction of the issue.

  4. Go to, fill out the mandatory fields, and set the Priority of the incident to 5.

  5. Save the record.

    The SLA you have just created is attached.

  6. Wait for 3 minutes.

  7. Once the SLA is breached go the Task SLA [task_sla] table, right-click in the header, and choose History > List.

    Note that Has Breached has been updated twice as it has the same update number.

    Note – You might have to follow these steps several times (usually within five tries) for this issue to occur).




  • If you are able to upgrade, review the Fixed In or Intended Fix Version fields to determine whether any versions have a planned or permanent fix.

  • For a temporary fix in Jakarta and Kingston:

    1. Import one of the attached fix files:

      • Jakarta: sys_script_include_c31eac7deb62310070a9666cd206feee.xml
      • Kingston: sys_script_include_c31eac7deb62310070a9666cd206feee.xml
    2. In both Kingston and Jakarta, import the attached sys_script_include_f761fc81373331003e7d40ed9dbe5d10.xml file into your instance.

    3. Modify the Default SLA workflow as shown in the following figure.



    4. Similarly modify the SLA Notification and escalation workflow & Default SLA Repair workflows, as shown in the following figure.




Related Problem: PRB1090831

Seen In

SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Risk Management - New York 2019 Q3
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - VR - Qualys - New York 2019 Q3
SR - VR - Vulnerability Response - New York 2019 Q3

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-02-11 21:40:06
DefaultSLAworkflow.pngDuplicate Has breached records with the same Update number in task_sla history audit.pngslaWorkflows.pngsys_script_include_c31eac7deb62310070a9666cd206feee.JAKARTA.xmlsys_script_include_c31eac7deb62310070a9666cd206feee.KINGSTON.xmlsys_script_include_f761fc81373331003e7d40ed9dbe5d10.xml