If you create an SLA definition with the following two characteristics, any record created outside of this schedule does not have the proper calculated planned end time for Task SLA:

- a custom duration of 'End of current business day if before 12:00pm' and 'End of next business day if after 12:00pm' through a script (attached)
- a schedule (for example, 8-5 weekdays)

Steps to Reproduce

  1. Create an SLA definition with these settings:
    • Table: Incident (or any table)
    • Workflow: Default SLA workflow
    • Duration type: the script attached to this PRB (all this script does is that it increments the planned end time by 1 day if start time is past 12:00:00)
    • Schedule: 8-5 weekdays (or create a new one with shorter duration for testing purposes like 8-1)
    • Timezone: US/Eastern
    • Start condition: State is active
    • Stop condition: State is false
  2. Now create an incident record with state = active
    The Task SLA should be attached. The Planned end time is still on current date, but it should be the next business day.


In the DurationCalculator script include, replace the calculator.isAfter() function with an appropriate call to GlideDateTime. The Geneva version of this script (XML file attached) can also be used.

For example:

In the relative duration 2 business days by 4pm, there is the following code:

// If the current time is after 10:00, add another day
if (calculator.isAfter(calculator.startDateTime, "10:00:00")) {

If your business day is 8AM to 5PM weekdays, the if statement will not evaluate correctly after 5PM.

Change the relative duration script to:

// If the current time is after 10:00, add another day
//if (calculator.isAfter(calculator.startDateTime, "10:00:00")) {
if ((new GlideDateTime()).getLocalTime().toString().substring(11) > "10:00:00" ) {

Note that the workaround assumes the SLA processing is running synchronously (under the user's session) and not asynchronously (under a worker thread).  If the user has a different time zone set than the system default time zone, the script can produce different results because of the getLocalTime() function.

To make this work properly with asynchronous SLA processing, change the worker thread's time zone to the time zone of the person who opened the task, execute the expression, and then set it back to system time using code similar to the following:

var openersZoneName = current.opened_by.time_zone;
var originalZoneName = gs.getSession().getTimeZoneName();

<code that needs to run under the user's time zone>


Related Problem: PRB624023

Seen In

Dublin Patch 3 Hot Fix 1
Fuji Patch 10
Fuji Patch 11
Fuji Patch 13 Hot Fix 1
Fuji Patch 2 Hot Fix 1
Fuji Patch 7 Hot Fix 5

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2017-03-30 08:17:53