Resolve time met but the request is still breached - Resolution timer

[Rashid.Ahmed]

 Hi,

I've scanned the forum to see if anyone had already posted this issue, but could've missed it, so please do point me to it if this has already been raised.

One of our managers ran a report for the month of March and came upon a discrepancy whereby even though the request resolve by and the date resolved were met, the within resolve time criteria was still appearing as breached (see attached spreadsheet)

We applied the Pause Resolution Timer enhancement on the 2nd of March so these calls should adhere to this setting - we confirmed that the enhancement works after the latest update released on the same day

One thing we did notice for the tickets where this issue exists is that the resolution missed is way in the future, well after the call has been closed and timers ended

is this a known issue?

 

Application Support - resolved calls by analyst - with SLAs_629.xlsx

[David Hall]

Hi @Rashid.Ahmed

It does look incorrect but its pretty hard to confirm from the screenshot, sometimes changing an SLA after a target has already been missed etc can result in this view for example. 

If there has not been an SLA change to cause this scenario, if you have the "Incident Management Full Access" role you should be able to click on the blue button under "Service Level" to open the SLA update popup.  To the bottom right of the popup there is a diagnostics button which will show a list of the primary SLA actions e.g. pause/resume etc.  It might be worth checking that to see if that shows when the pause and resume took place and when the resolution/fix target was marked to see if that highlights any reason for the above.

Kind Regards,

Dave

[Rashid.Ahmed]

Hi @David Hall

Sorry about the belated reply

So i've given your instructions a go and using the above ticket as an example i can see that the timer was paused once i resolved the issue, it was then marked as fixed when the ticket closed automatically on the 30th

The system then resumed the timer almost immediately, is that correct?

I can see that this was the case for the other tickets mentioned in the spreadsheet too- Pause once resolved, then Mark Fixed and resume almost immediatly

The ticket is pretty simple in terms of the tasks and the timeline - see below

[Rashid.Ahmed]

Hi @David Hall

Further to my update above

The escalate row has the following info attached to it:

 

{
  "detail": "Resolution Timer Escalated\r\n* The target resolution time has been changed from '''[2021-04-07T15:55:00.000Z]''' to '''[2021-03-29T15:55:00.000Z]'''",
  "flowcode": "smSLMEscalateResolutionTimer",
  "prevSysTimerElapsedWorkingTime": "PT0S",
  "prevSysTimerElapsedTime": "PT6S",
  "prevSysTimerslcName": "ServiceDeskDefaultCalendar",
  "prevSysTimerstartTime": "2021-03-22 17:52:40Z",
  "prevSysTimerstate": "1",
  "newSysTimerElapsedWorkingTime": "PT0S",
  "newSysTimerElapsedTime": "PT0S",
  "newSysTimerslcName": "ServiceDeskDefaultCalendar",
  "newSysTimerstartTime": "2021-03-22 17:52:46Z",
  "newSysTimerstate": "0"
}

And the Resume status set by the system states this:

{
  "detail": "The resolution target has been resumed",
  "fixTime": "2021-04-07 13:25:06Z",
  "previousFixTime": "2021-03-29T15:55:00.000Z",
  "systemTimerElapsedWorkingTime": "PT2H31M58S",
  "systemTimerElapsedTime": "PT181H39M18S"
}

[Rashid.Ahmed]

Hi @David Hall

Just wondering if this has been found to be a bug or if a fix can be proposed?
Regards

Rashid

[David Hall]

Hi @Rashid.Ahmed

Sorry I've been on leave hence the lack of recent reply.  Based on the debug info you have posted let me review and see if I can determine what is happening in this scenario.

Kind Regards,

Dave.

[Rashid.Ahmed]

Hi @David Hall

Thank you David, really appreciate it!

Kindest Regards

Rashid

[David Hall]

Hi @Rashid.Ahmed

Just to check.. are you using the BPM nodes to control the pause/resume or are you using the app settings e.g. app.request.pauseResolutionTimerOnResolve to do it automatically?

Kind Regards,

Dave.

[Rashid.Ahmed]

Hi @David Hall

We are controlling the pause/resume resolution timers function via the Service Manager Settings:

 

Continuing to use the ticket SR00034450 i've been using for screenshots in this post

In the BPM for this call, the 'classification stage' is the only place we have Timer Type nodes set; we don't have timer nodes set in the 'Fulfilment & Closure' stage
The timer nodes we have during this stage seem to only be nodes to start the timer
 

 

 

[David Hall]

Thanks @Rashid.Ahmed I'll take a look to see what I can find.

[David Hall]

Hi @Rashid.Ahmed

I've still not been able to fully replicate locally but I have a suspicion it could be down to the fact the request was raised out of working hours and then escalated immediately before any time elapsed.  I'm just trying to recreate that scenario to see if I can confirm whether that is the reason for the resolution time being incorrectly reset.  Will let you know when I can confirm or not.

Kind Regards,

Dave.

[Rashid.Ahmed]

Hi @David Hall

Thank you for coming back to me

Your update above got us looking at all the calls that are breached like this again

1. We can definitely see calls raised via the self service portal, during working days/hours

2.  We could see that Hornbill was still registering that the resolution was met in some way, as when you hover over the breach you can see when the call was actually closed by the system and when all the SLAs should have been taken off pause and stopped ticking complely

3.  With just this ticket as an example (we have many since the resolution timer pause change was made) you can see that this call was due breach on the 29/03 at 4:55pm. It was actioned and set to resolve on the 23/03 11:01am

The call had around 6 days 19 hours left in the SLA - the real time taken to action the call minus off the 7 day SLA for this call.

It looks as if Hornbill is placing the call on pause until it is ready to auto-close, but then decides to carry on counting down from the date of closure

The date in the future is what the breach time would be if the call was re-opened on the 30th and left to tick over

[Rashid.Ahmed]

Hi @David Hall

Apologies for the various chasers

Just to let you know, Some more examples from April of Service Manager incorrectly recording a call as breaching the resolve timer when it clearly hasn’t.

Edited May 10, 2021 by Victor
Personal data included in screenshot

[Victor]

@Rashid.Ahmed please be more mindful when posting screenshots or other information that contains personal data. The screenshot above has been edited and personal data removed.

 

[Rashid.Ahmed]

@Victor
My apologies Victor, I'll be more mindful of what i post on the forum in the future

Your linked post is really helpful to outline what shouldn't be posted on the forum - i've passed the info onto my colleagues too :)

[Rashid.Ahmed]

Hi @David Hall

Has there been any further developments regarding this issue? Is this potentially a bug? Should we roll back the resolution timer change?

Do let me know

Regards

Rashid

[Victor]

@Rashid.Ahmed this is a bit more difficult to troubleshoot just via a forum conversation. Although you don't usually have access to this type of support as an Essentials Customer, due to the investigation we need to perform I will raise an internal request with our support team to progress this further. You will receive a notification in this regards shortly.

[David Hall]

@Rashid.Ahmed

Apologies, its taken quite a while to track down the cause of the issue in this case, however I'm glad to say we have managed to replicate the issue and have fixed this for the next update of Service Manager (update > 2368)

Kind Regards,

Dave.

[Alberto M]

Hi @David Hall.

Is this related to the defect KE00166401 ?

We have intermittent issues with SLA timers for months.

Regards,

Alberto

[Victor]

@Alberto M no, the KE00166401 is different.