I assume you mean the following fields:
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. /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. /nav_to.do?uri=sys_script.do?sys_id=bf3f8917c0a8016400a867dc0794e8ad
3) (sc_task) Close Ticket. /nav_to.do?uri=sys_script.do?sys_id=74d38bd0c611227d0151ca6b62ae87e6
4) (change_task) Close Ticket. /nav_to.do?uri=sys_script.do?sys_id=9023ada50a0a0b01004228007704cf66
5) (problem) mark_closed. /nav_to.do?uri=sys_script.do?sys_id=12a53c4fc6112275000bc7c04a87cfb6
6) (change_request) mark_closed. /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 main goal of the duration and business duration fields are usually to enable reporting on Mean Time to Resolution (MTTR). In other words, you want to know how long it is taking to resolve your incidents/problems/etc.
In my humble opinion, this is how I would rank different MTTR solutions:
#1 Performance Analytics
This is by far the most powerful option. You can get Performance Analytics for Incident Management for free.
Context: The ABCs of Performance Analytics - Part 2 - part 2 of a very helpful 3 part discussion about using Performance Analytics to drive KPI's, including MTTR, backlog and many more.
Moneyball for Enterprise Service Management (ServiceNow) - Another discussion about how Performance Analytics enables deep insight into KPI's including MTTR.
#2 Metrics
This method uses Database views to report against calculated Metrics (metric_definition, metric_instance)
how to generate MTTR report for resolved period of time - talks about how to use Metrics
Re: MTTR (Mean Time to Resolution) Reporting - Talks about how to use Incident Metric to report on MTTR
MTTR Report - Talks about how to use Incident Metric to report on MTTR
#3 Service level agreements
Each task SLA has business duration and duration fields. Hypothetically MTTR would be equivalent to business duration on an SLA that measures resolution. You can report against the task_sla table to find out how many SLAs are meeting their different targets, including separating them out by SLA type - such as those SLA's whose name starts with the work "Resolution".
Re: Mean Time to Resolve - Reporting - Discusses using SLA's to measure MTTR
#4 Manually implementing business duration and reporting on it
Business Duration on new table - talks about how Business Duration and Duration are actually calculated and how a scripted solution could enable them on new tables that extend task. Also discusses the option of reporting off SLA's. FWIW, my personal research seems to indicate that 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.
Re: Business Duration vs. Duration - some details about how mark_closed and mark_resolved business rules work and the deprecated method calDateDiff that worked with Calendars (deprecated in favor of Schedules many years ago)
Re: Business_duration calculation confusion - Discusses some struggles to get Business Duration and Duration to work as expected.
