Guidance on Applying New SLAs to Historical Incidents in ServiceNow

[Ballela Siva Te]

Hi Team,

In our ServiceNow instance, we currently handle P3 and P4 incidents separately, with SLAs set at 2 business days for P3 incidents and 5 business days for P4 incidents. The inflow of P3 incidents is significantly lower compared to P4 incidents. Due to this, the business has requested combining both P3 and P4 incidents under a single SLA of 3 business days.

However, our SIAM team has raised concerns that a 3-day SLA could lead to incident breaches and potential penalties. They have therefore recommended that we instead set the SLA to 4 business days.

To help in making an informed decision, the SIAM team has requested that we implement two SLAs—one for 3 business days and the other for 4 business days—and apply these  to closed or resolved incidents. This way, they can analyze historical incident data and provide a recommendation to the business.

My Question:
Is it possible to apply these new 3- and 4-day SLAs  to past closed/resolved incidents in ServiceNow?  . If so, could you advise on the best approach to achieve this in a way that accurately reflects potential SLA performance for historical data?

We also came across a concept called repair SLA, Can we apply it to closed/ Resolved incidents as well

[Simon Christens]

Hi

You should be able to make some tests in a non prod instance
Make some sample SLAs and go to a specific incident. Under related links there's a "Repair SLA" that can be used to see if the expected result is returned.

Also - there's a script include: SLARepair

It got a method that can be called with the same result as the UI action which call a client callable script include: 

SLARepairClient

This is the method from the server sided script include.

/**
     * Repairs SLA records from scratch based on sys id and tables name removing current data and creating new task_sla records.
     *
     * @Param sysId - String sys id
     * @Param sourceTable - String table name (task or extension of task, contract_sla, task_sla)
     * @Param currentUser - String sys_id of the user to use for audit records (Optional)
     *
     * @returns an SLARepair.Response object (see EOF)
     */
    repairBySysId: function(sysId, sourceTable, currentUser) {
        if (currentUser)
			this.currentUser = currentUser;

        this.repairAction = SLARepair.RECREATE;
        this._bySysId(sysId, sourceTable);
        return this.response;
    },

Make some tests and see what happens.

The good part here is that you can use a single record to begin with to make some structured tests initially.

I have used it a couple of times to mass repair Incidents - as long as the states doesn't change then you shouldn't encounter too many challenges.

[Ballela Siva Te]

Hi,

Thanks for the explanation, Can you please let me know if this can be implemented for closed/resolved incidents

[Simon Christens]

As long as the SLAs are set up "correctly" and Audit history is available (for how long was an incident in each state - pause conditions, complete conditions etc) then it should recalculate correctly.

I will suggest though that resolved will pause the SLA and Closed will Stop (complete) the SLA as you dont know if an incident is fixed once it Resolved (User can reopen the incident)

I do think that you will get a very nice visual overview once you create new SLAs - You can specify them for VERY specific start conditions to begin with so that only a small batch of incidents will be impacted in the non prod instance. The only challenge can be lacking of history data in non prod instances but thats another story 🙂

[Ballela Siva Te]

Thanks for the explanation. My question is that repair SLA can we applied to resolved/closed incidents ? or if there is an other way to recalculate the SLA for incidents what is the approach in step by step manner