Duration time for Requests

[bradschamerloh]

Currently, OOB is not setup to populate the Duration fields in RITM's.   Anyone know how to set this up?

[Mwatkins]

I assume you mean the following fields:

task	Business Duration	business_duration
task	Duration	calendar_duration

(NOTE: The below information was composed in Calgary Controlled Availability 6 and may be out-of-date)

Explanation of the Duration and Business Duration Field

HISTORY

• The Business Duration field was used as part of the old pre-2010 SLA engine (completely obsolete and not supported). Most customers no longer use this field.
• The Duration field is also left over from earlier versions of the product and there are better ways of getting the information that it provides.

HOW THEY WORK

There are a number of Business Rules that handle these operations for the various task tables. As of Calgary CCA6 here are the related Business Rules:

1) (incident) mark_resolved will set these fields when the incident_state goes to the resolved. https://<<instancename>>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=d3b21f640a0a3c7400f6acab7de3f5f8

2) (incident) mark_closed will set these fields (if not already set by the the above rule) when the incident_state goes to closed. https://<<instancename>>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=bf3f8917c0a8016400a867dc0794e8ad

3) (sc_task) Close Ticket. https://<<instancename>>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=74d38bd0c611227d0151ca6b62ae87e6

4) (change_task) Close Ticket. https://<<instancename>>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=9023ada50a0a0b01004228007704cf66

5) (problem) mark_closed. https://<<instancename>>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=12a53c4fc6112275000bc7c04a87cfb6

6) (change_request) mark_closed. https://<<instancename>>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=6e20e124c611228e00e44dd37ad1b842

calDateDiff

Durations are calculated based on the closed time when an incident is closed. Not when it is resolved. This is done by the "mark_closed" business rule on the incident table, for example. The rule will also use only 1 calendar and so the duration length will be based on that calendar where the 2 days of duration would represent 48 hours of calendar time.

In all cases (except "mark_closed" on change_request) these use the GlideSystem function calDateDiff

current.business_duration =gs.calDateDiff(current.opened_at.getDisplayValue(), current.closed_at.getDisplayValue(), false);

The calDateDiff function does not use a schedule but rather uses the calendar (System Policy -> Calendars). You only have 1 calendar which is "Monday thru Friday (9 - 5)".

If there were more than 1 calendar then it would just use the first one that it finds and so it is best to change the 1 calendar to what you want. This is because calDateDiff uses the default calendar. In other words, the first record in the sys_calendar table arbitrarily returned by the database.

( See the WIKI http://wiki.servicenow.com/index.php?title=GlideSystem_Date_and_Time_Functions#calDateDiff.28String.... )

All of the above is not very flexible and that is why the new (post June 2011) SLA engines use Schedules and also handle time zone issues better. With the old calendar, you really only have 1 timezone that must fit everyone.

NOTE: We suggest that you don't use calDateDiff function when tailoring your instance. It may work in our out-of-box scripts, but that is because they were created at a time when it was the recommended way to do this. calDateDiff is now legacy (i.e. deprecated).

Close Ticket

For change_task and sc_task, Business Duration should be calculated in the business rule "Close Ticket"; which will compute the "business duration" value when the task initially gets moved to closed. For instance, if a change_task goes to Closed Incomplete (3) or Closed Complete (4) then the business rule does it's calculations.

One caveat is if the work_start, work_end fields are changed without also changing the state to 3 or 4 then the calculations won't run again. This could lead to a situation where business_duration wouldn't match the expected value based on work_start, work_end.  

ALTERNATIVES

The information provided by the Duration field can be gathered much better using the Metrics capabilities. Metrics exist on your system that capture "Create to Resolve Duration" and are probably what you are interested in rather than Duration or Business Duration field in the incident. We provide a report called "Incident Create to Resolve Duration" out-of-the-box.

Each SLA record (task_sla table) has it's own Business Duration calculation field. Since each incident may have multiple SLA's attached to it, it is recommended to use the duration fields from the SLA tables rather than from the task tables (incident, change_request, etc.).

[bradschamerloh]

I'm looking for duration to populate in a Requested Item.   What you referenced above covers Incidents, SC tasks, change tasks, problems and change requests.

[Mwatkins]

My hope was to demonstrate to you some ways that the fields have been used and some alternatives to using the fields so that you could design your own solution.

[Brian Workman]

I am also looking at figuring out why my sc_task items do not properly set the business duration as it does in incident.

I checked the BR you described Close Ticket on sc_task and I added some logging and discovered that it does in fact run when I close a task.

current.active = false;
current.work_end = nowDateTime();
current.business_duration = gs.calDateDiff(current.work_start.getDisplayValue(),current.work_end.getDisplayValue(),false);
gs.log("THIS JUST RAN!");
gs.log("BUSINESS DURATION: " + current.business_duration.getDisplayValue());

... however, it does not actually appear to be setting it.

When I look at the logs, I see:

Any thoughts on what might be preventing the field from being updated? On Jakarta.