Jump to content

Response time in Request export does not seem correct


Recommended Posts

We exported Request data from the Request list including Service Level Target (SLT) attainment fields "Response Time" and "Resolve Time" and found a large number of our Incidents had the 28810 seconds entry for response time (8 hours as per the SLT) and this was even happening when it's clear from Resolve Time that the Request had been resolved in around 1 minute:


I thought for a moment that I was missing a "Mark Response Timer" node in that BPM but on examination of these Requests we see that the Response Timer was Marked only a few seconds after the Request was logged:


So what I see is that the data in Resolve Time on Request Export does not match my expectations of what it should be. I am expecting for these IN for the Response time to be a few seconds, not seem to default to the 8 hours in the SLT.

Interestingly the flag for "Within Response time" is 1 for these cases indicating that the system DOES know there was a quick response...

Is this something I have not correctly configured or something I need to report to Support?



Link to comment
Share on other sites

  • 2 weeks later...

I don't think so. There is only the "Starter Response Timer" node and "Start Resolve Timer" node; both at the start. There is only one "Mark Response Timer" node and then the next SLA-affecting node is "Mark Resolve Timer". We don't have any re-evaluate SLA workflow nodes to escalation rules in play. The only re-evaluation would occur if someone altered the priority I guess?

I noticed this: the "Start Resolve Timer" has no Result Reference


but the "Mark Response Timer" one does have a reference:


Link to comment
Share on other sites

OK so my Incidents WERE going through an "SLA Re-evaluation" node (now removed) and we have guest.app.view.ITSM.serviceDesk.slm.enableAutomatedSLChanges set to on so we got this in the timeline (although I can't understand how two nodes that are supposed to do the same thing came out with different answers within seconds...)



Are we saying that any re-evaluation (be it the node in BPM or the automated process) NULLIFIES any chronologically previous "Mark Response Timer" node outcome?

I'm a bit worried you're going to say 'yes' to that because a Response is a Response and it's done and thus any re-evaluation should only re-evaluate that which has yet to be given an outcome?

And yet even if it does, it does not stack-up with the situation where, in my dataset in the first post, we are getting a "1" flag in the "Within response time" column for IN00052304 which does not tally with the "Response Time" number of 28813 seconds; and the UI states, "Response Completed: 04-10-2022 16:13" so a response was logged.

Link to comment
Share on other sites

Ah, @Victor I think we have hit it. That's a big issue for us because we need to alter priority quite a lot (we see it as a dynamic field to help us 'prioritise' hehe) so this would explain why all our values are 28810 seconds; many SR and IN get priority altered and so they all lose any response timers they may have had.

Any view on whether this is scheduled for a release? 

Link to comment
Share on other sites

In the meantime, I have moved the Start Timers (both of them) to be AFTER the automated priority setting so that will stop some of the issues. I have removed the manual re-evaluate node.

We are not yet reporting this data so we do have an indeterminate period before the management team get visibility of the issue. I am trying to get thing in line before we start reporting on response times.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...