Where do SLA Schedules come from?

[cecilialehmann]

Where do the SLA schedules get populated from? After we upgraded our ServiceNow instance to Istanbul, our SLA's are no longer populated for incidents (they still work for tasks). We can see that the "schedule" field references cmn_schedule, but it dosn't actually populate anything in the "schedule" field, thus having all of our priority 4 and 5 incidents breach after 24 hours instead of their schedule, which is based on the group the incident is assigned to.

We have compared of pre-upgraded instance to an upgraded instance and everything seems to be the same.

[Dave Smith1]

System Scheduler > Schedules > Schedules have the schedules selectable in SLAs.

[Shishir Srivast]

You can file list by typing cmn_schedule_list.do in your filter navigation search window.

[cecilialehmann]

So where does the code come from that populates the cmn_schedule into the Task SLA on an incident? These have gone missing but we are unsure how to get them back and populated.

[edwajs]

Hi Cecilia,

There was an enhancement in Helsinki to allow the source of the schedule and timezone to be SLA Definition (contract_sla) specific. Prior to that, you would set properties for the source of the schedule and the source of the timezone, and they applied to all your SLA Definitions.   You could modify the SLASchedule and SLATimezone script includes, if you wanted to put in custom functionality for setting the schedule and timezone for specific situations.

The actual code you are looking for is the _newTaskSLAprepare() function in the TaskSLA script include.  

var schSource = contractSLAgr.schedule_source + ''; // default value: 'sla_definition', others: 'no_schedule' or 'task_field'

var scheduleId = SLASchedule.source(schSource, gr);

  // If we got a Schedule from somewhere based on the settings in the SLA definition

  // put it in the new task_sla record

  if (scheduleId) {

  var scheduleGR = new GlideRecord('cmn_schedule');

  scheduleGR.get(scheduleId);

  gr.schedule = scheduleGR.sys_id;

  gr.schedule.setRefRecord(scheduleGR);

  }

We read information out of the SLA Definition and use that as arguments to the SLASchedule script include, which is supposed to return a sys_id of the cmn_schedule record for your SLA.

Multiple customers have reported not getting schedules associated to their SLAs after upgrading to Helsinki or later.   There are two main causes:

#1 - The most frequent issue is the customer modified SLASchedule during an earlier release and the upgrade skipped the updated version of the code.

#2 - The upgrade updates new fields in the SLA Definition.   If the customer has taken an XML Import or update set from an older version and put them into their upgraded system, the fields may be NULL, and as indicated by the comment in the above code, NULL is not an expected value.

For #1, you want to revert to the out-of-box code.   For #2, you want to fix your SLA Definitions to make sure the schedule_source field is populated.

Ed Wajs

ServiceNow Technical Support