Repair SLA with new start time?

[mathiasjohansso]

Hi all!

Is it possible to Repair SLA's and set new Start Time on the task_sla's?

We have been struggling with correctly defining SLA definitions and different start times.

Now, the "Set Start To"-field on the SLA definition is set to "u_vendor_start_time" which is a custom field on the Task-table.

However, when repairing SLA's on tickets which was created before this field was set on the SLA definition, the Task SLA on that ticket will not set the Start time to the same value as u_vendor_start_time..

From what I understand, the Repair SLA function creates new Task SLA's and attaches them to the ticket, based on the history of the former Task SLA's..so how can I set this "new" Start Time and recalculate the SLA?

[mathiasjohansso]

Yes, SLA Logs are active

[michaelrauch1]

Did anything come of this? I am trying to understand what SLA Repair even does. Is this just so if someone changes the SLA definition they can recalculate the SLA time on the new definition?

I am trying to be able to edit the SLA after the fact.

For example someone opened an MIA today but we come to find out that the issue causing the outage was actually happening the day before. So the SLA admin wants to move the start date from today to yesterday to accurately track the duration of the MIA.

Another example would be that we had an SLA run for 12 hours but in the middle there were 6 hours that the sla admin doesn't believe should be counted. So they want to manually add a 6 hour hold time after the fact. ----- this isn't the greatest example but this is what the SLA admin is requesting.

[Dave Smith1]

Another example would be that we had an SLA run for 12 hours but in the middle there were 6 hours that the sla admin doesn't believe should be counted. So they want to manually add a 6 hour hold time after the fact. ----- this isn't the greatest example but this is what the SLA admin is requesting.

I'm not sure what an "SLA admin" is, but... this 6 hours could have been removed in one of two ways:

• pause condition
• schedule

It sounds like your SLA definition may not be set up right.

I am trying to be able to edit the SLA after the fact.

That's not what SLAs are for.   Cancel the SLAs, clarify and redefine then implement.

You don't get customers signing a legal document then impose changes because it was never spell-checked.

(disclaimer: I know an SLA isn't a legal document, but it serves as the challenge of deploying something incorrect then trying to correct it in production)

[michaelrauch1]

Thank you for the reply. In the definition of SLA repair it mentions sla administrators. We have a person or a group of people that go over the times that are recorded and reported to customer. They don't currently use SLA today but i want to move them to this because we do things like what is described above and that was some questions they had. Im hoping in the future the definition/process will work correctly.

I have never had the ask to edit SLA data and im glad servicenow takes the firm route of your definition/process is broken.

[Dave Smith1]

We have a person or a group of people that go over the times that are recorded and reported to customer. 

I would expect a Service Level Manager to do this - assessing if services are being delivered to the agreed levels.

I have never had the ask to edit SLA data and im glad servicenow takes the firm route of your definition/process is broken.

That's my opinion, rather than SN's... but yeah, editing feels wrong to me.

The point of SLAs is to provide monitoring and alerting, an oversight activity that contributes to governance.   Tweaking times/dates here and there feels like someone's altering truth to suit their skewed viewpoint of "meeting targets".   Even "Reset Condition" to me feels somewhat deceitful.

Ultimately it does sound like more analysis and design is needed.   One particular failing in SLM is SLAs being constructed without considering the underlying OLA/UCs, meaning commitments made without fully understanding delivery capability, then trying to cope with over-promising and under-delivering.   It's quite commonplace, and although simple to avoid it's symptomatic of a culture that views the ITSM infrastructure purely as a supply mechanism and not as a valued stakeholder in the design process.