Service Level Agreements: Business Hours, Schedules & Time Zones

[edwajs]

A Service Level Agreement (SLA) definition may need to apply only during the business hours of an associated group or organization.   To define business hours, you need a schedule with entries for the working hours and exceptions for holidays. Since 8AM to 5PM in London is going to be 3AM to 12PM in New York, you also need the relevant time zone to apply to the calculations.

If the definition does not have a schedule, then only actual hours need to be calculated, and it is normal date arithmetic, i.e., you are not needing to subtract the time outside the schedule.   If you create a 24x7 schedule and apply it to your SLA, the business values will be calculated but they will be the same as the actual values and it is wasted work.

Defining the Schedule and Time Zone

You specify the schedule and time zone to use with the following two properties:

• com.snc.sla.schedule.source
• com.snc.sla.timezone.source

These properties are available under the SLA Properties module in the Service Level Management application.   In Geneva and newer, this has been changed to Properties > SLA Engine.

For the time zone, there are five choices provided in the base system; and these are probably sufficient for the majority of customers:

For the schedule, there are only two choices provided in the base system:

Based on these properties, when a new SLA data record (task_sla) is created, the corresponding schedule and time zone are applied to the calculations.   The schedule reference and time zone are stored in the SLA data record and used for future updates.

There are two drawbacks:

1. The number of possible sources of the schedule is limited in the base system.
2. You cannot override the schedule and time zone with a before-insert-update business rule on task_sla, because the initial set of calculations occurs before the business rule can override the values.

The reason for the second drawback is because the SLASchedule and SLATimezone script includes are called in the early stages when the SLA Engine creates a new SLA data record.

These script includes do the processing of the system properties and fetch the specified schedule and time zone.

Changing the Schedule and Time Zone Sources for Service Level Agreements

There are two steps involved in providing additional choices for either the schedule or the time zone:

1. Edit the Choices field of the desired property to provide any additional label/value pairs you want to add.
2. Edit the SLASchedule or SLATimezone script include, as appropriate, so it supports your additional choices.

The important thing to remember about editing either SLASchedule or SLATimezone is to make sure the function is returning the expected value.   SLASchedule returns a reference value (sys_id) to a valid existing cmn_schedule record in the instance.   SLATimezone returns a string which needs to be a valid Olson time zone.

Example of Changing Properties, SLASchedule, and SLATimezone

Business Requirements:

• Add a schedule field and a time zone field to the task table.
• Set the schedule and the time zone via a business rule.
• Use the new task schedule and time zone fields in SLA processing.

Add a schedule field and a time zone field to the task table

To add these fields to the task table:

1. Navigate to task.do?sys_id=-1
2. On the task form, use Configure > Form Layout to add the two new fields.

   

   

3. For the new u_sla_time field, configure the sys_dictionary entry to use the choices for time_zone from the sys_user table.

   

Set the schedule and the time zone via a business rule

For the purposes of this example, we want to use the schedule and time zone of the task's assigned_to user for our SLA calculations.   All we need is a simple before insert and update business rule on task where, if assigned_to is not empty, we set the new u_sla_schedule and u_sla_timezone fields to the dot-walked values from the assigned_to reference.

Use the new task schedule and time zone fields in SLA processing

Here is the changed com.snc.sla.schedule.source system property:

Here is the changed com.snc.sla.timezone.source system property:

With the properties updated, the final steps are to update the SLASchedule and SLATimezone script includes so they support the new properties.

First SLASchedule:

Then SLATimezone:

Now, when a new task_sla record is created, the schedule and time zone applied are going to be from the task record; however, the values in the task record are pulled from the assigned_to reference.

In this case, I have populated a sys_user record with a time zone of US/Eastern and the schedule 8 to 5 weekdays excluding holidays.   Here are the results of creating a new priority 1 incident assigned to that user:

In summary, Service Level Agreements will always calculate Actual values of based on no schedules. Once you apply a schedule and a time zone for a Service Level Agreement, you need to define Business hours so business values can also be calculated.

The base system provides the capability of choosing between five different sources for the time zone and two different sources for the schedule to apply to the SLA calculations. If you want to override the base capabilities, the example illustrates the required changes to the system properties and script includes. Finally, if you have business requirements to have different time zone and schedule behavior for different task types, you can accomplish this by following the example, but implementing different business rule logic for each different task type.