Resolve Time Column does not captures the time when the ticket is resolved
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-13-2011 03:14 PM
Once we enter into the Incident Management>All incidents, we find Resolve time column on the displayed table.The "Resolve Time" field is automatically updated when a ticket is put in a "Closed" state, this field is not updated in any other state.The "Resolve Time" field should get updated once the status of the ticket changed to "Resolved".
Any ideas would be helpful here.Please help in fixing this urgently.
Can you please provide us the script/code for this business rule to capture date and time once the ticket is marked into "Resolved" state.
- Labels:
-
Incident Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-13-2011 03:58 PM
There are two different business rules my instance handle the population of the "Resolve Time". Interestingly enough it's DB name "calendar_stc" which would not identify it as "Resolve Time" to me. Anyways, in demo.service-now.com there appears to be only one. Just like you mentioned, when it gets closed (mark_closed). Which is odd. I have a business rule on the incident table and called "mark_resolved". It pretty much does the exact same thing as the mark_closed, just has a different condition. Here it is. Just create one if not already there, and you should be good to go.
if (current.state == 6) {
//Incident is resolved so set the closure info
current.closed_by = gs.getUserID();
current.closed_at = gs.nowDateTime();
// now we want to update the fields that indicate the time
// or duration of this incident from open to resolve. We keep
// track of duration as a glide_duration value (dd hh:mm:ss) and
// as a pure number of seconds.
//
// Both calendar time and business time are maintained
current.business_duration =
gs.calDateDiff(
current.opened_at.getDisplayValue(),
current.closed_at.getDisplayValue(),
false);
current.business_stc =
gs.calDateDiff(
current.opened_at.getDisplayValue(),
current.closed_at.getDisplayValue(),
true);
current.calendar_duration =
gs.dateDiff(
current.opened_at.getDisplayValue(),
current.closed_at.getDisplayValue(),
false);
current.calendar_stc =
gs.dateDiff(
current.opened_at.getDisplayValue(),
current.closed_at.getDisplayValue(),
true);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-13-2011 04:50 PM
Thanks MB. Let me try it out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-13-2011 06:51 PM
Hi MB,
I used this script and guess it does capture time duration but it is seconds only. We need the actual timestamp when the incident is marked "Resolved" in mm/dd/yyy hh:mm format.
Can you please help us on that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-14-2011 07:59 AM
So you have a few different options for this.
- There is a "Business Duration" (business_duration) field that also gets populated in the business rule I sent you. It will calculate the amount of time from when the task was opened to when it was closed. That outputs in this sort of format "3 days 11 hours 8 minutes".
- If you want an actual date time field you could create another field and populate it with a business rule. You would create a Date-Time field, name it what you want, and use a "gs.nowDateTime();" function in your business rule logic to populate it with the date/time. This would give you the actual date/time in the "mm/dd/yyy hh:mm" format, just as the other glide date/time fields.
- Another option I could suggest is to use the Metric Definition Plugin. (http://wiki.service-now.com/index.php?title=Metric_Definition_Plugin). There is a metric definition OOTB, called "Create to Resolve Duration". It will keep track of the Task Start time, Resolve Time, and Create to Resolve duration. Reporting using metrics is slightly different as you will have to report from a different table, than the actual incident table.
Hopefully these ideas help.