Historical incident state time Report

daniziz
Kilo Contributor

Hi All,

I've been doing some research about how to get a report were I can check hoy much time spend an incident on a determinated state (Something like: "New"->19mins, "In Progress"->3h)

I've checked about metrics and "inbox" incident_metric database view, which gives me a pretty close approach of what i want:

find_real_file.png

 

The thing is, as you can see in the picuture, the table only "records" or looks like it records the last state of the incident, not the historical...

What am I doing wrong?

Kind Regards,

 

Daniel.

1 ACCEPTED SOLUTION

Waleska
Kilo Guru

Display the column named "Value". Incident State is going to show you what the current incident state is, whereas the Value column will show you the value for that specific metric.

Hope this helps!

View solution in original post

4 REPLIES 4

Waleska
Kilo Guru

Display the column named "Value". Incident State is going to show you what the current incident state is, whereas the Value column will show you the value for that specific metric.

Hope this helps!

heiber08
Giga Contributor

Hello, 

I am serching for the same thing as daniziz, but I want to see these data for service requests (RITM Tickets). I can't find the table, where these information about all the different states a service request had are saved.

Is there a way to see these data?

Kind regards, 

Philip

Josh Cooper
ServiceNow Employee
ServiceNow Employee

For Requested Items, it'll work pretty much the same way, only it's not there for you out of the box.  

If you go to Metrics Definitions you can take a look at how the Incident State one is configured, then just make a new one like it for Requested Item.

The table you want is called sc_req_item (for requested items, it's just sc_request for the parent request), and then make sure you've picked the state field and "Field Value Duration" as the type, and it should being collecting those metrics every time the Requested Item record is updated.  

It uses an After business rule that runs after the record updates to see if any metric definitions apply, and if so it creates an entry in the Metric Instance table for that record-metric combination.  Since the business rule is set up on Task, you shouldn't have to do anything for sc_req_item to work, since it's also extended from Task, like incident.

Josh Cooper
ServiceNow Employee
ServiceNow Employee

Take a look at Metrics.  They run against other task tables and provide additional information about the tables and field value durations, and State should be out of the box (though it may not be enabled.)

To ensure it's enabled:
Go to Metrics -> Definitions in the application navigator (if you're in Madrid, this will look different for you, but it should still be there)

find_real_file.png

Make sure the entry for "Incident State Duration" is set to Active = True and Timeline = True

find_real_file.png

If you're lucky, it's already set that way and you'll have some data, but if not, once true it will begin calculating from that point forward.

One way to confirm it is to look inside the definition and it will show you incidents it's been calculated for, but this isn't the most attractive way to look at the info:

find_real_file.png

But you can see that for each incident, for each state, it has a start and end time, calculated duration and a note as to whether the calculation is complete.

A better way to see this is to add the Metrics related list to the incident table, then the metrics will be displayed in context of that specific incident, and include all metrics tracked for the record:

find_real_file.png

But the coolest, in my opinion, is the metrics timeline (the second true we checked earlier), which gives you a graphical view of the metrics for a record:

find_real_file.png

So metrics are great for getting information on a specific record, but you can also use Performance Analytics to get that additional level of detail from the metrics table as well, that wouldn't otherwise be there.  For example if you wanted to know the Percent of Tickets that have been on Hold at some point, or one really good use case... tracking time spent with a specific assignment group, even if they're not the one who closed the ticket.

Hopefully this helps!