Incorrect scheduled job behavior when setting the calendar field - Known Error

Incorrect scheduled job behavior when setting the calendar field Description Incorrect scheduler behavior when a Calendar [sys_calendar] record with multiple entries per day is used on a Schedule Item [sys_trigger] record. The scheduled job only considers one of the entries defined in the calendar for any given day, ignoring any additional entries that might exist for that same day.

Steps to Reproduce

These are the steps to reproduce the error in an out-of-the-box instance:

Navigate to All > System Policy > SLA > Calendars and create a record in the Calendar [sys_calendar] table with multiple time entries defined for a single day. Typically, each entry is a different record in the Day [sys_cal_day] table. For example, you could create a calendar with two different time intervals defined for Monday: the first one 9-9:30AM, and the second one 10-10:30AM. Create a sample Schedule Item [sys_trigger] job record and select the calendar you created in Step 1 in the calendar field. A few considerations: The job should execute some action that you can easily observe on the instance; for instance, it could log a specific message. The job should have a trigger type that, in theory, allows for execution during both time intervals defined in the calendar. Taking the calendar described in Step 1 as an example, you cannot set the scheduled job to run daily at 9AM, as it would naturally skip the second time interval. The best way to observe the error is to set the scheduled job to run every few seconds/minutes. This can be achieved by using the trigger type "Repeat" or "Interval" and setting the repeat field to the desired frequency. Observe that the job selects one of the time entries defined in the calendar record and runs with the expected frequency. Note that this may not be the earliest time interval defined for that day. At the end of the time interval, observe that the job is immediately scheduled to run on a different day, regardless of whether the calendar has more time entries defined for that same day or not. The expected behavior would be that, for any given day in the calendar record, the scheduled job would run during the earliest time interval defined in the calendar and then move on to the next interval within the same day before looking at the next day.

Workaround The Calendar [sys_calendar] functionality has been deprecated in favor of Schedules [cmn_schedule], therefore the unexpected behavior will not be fixed. Instead, the recommended workaround for this problem is to create a schedule [cmn_schedule] to use in the script field of the scheduled job [sys_trigger] record as follows:

Navigate to All > System Scheduler > Schedules > Schedules and create a record in the Schedule [cmn_schedule] table. You can take a look at the ServiceNow documentation for how to define a new schedule and/or leverage existing ones: Schedules Documentation . Create a sample Schedule Item [sys_trigger] job record. In the script field of the scheduled job record, wrap your logic in a check to see if the current time falls within the time entries defined in the schedule [cmn_schedule] record: var gr = new GlideRecord('cmn_schedule'); gr.get( ); // Replace with schedule name var sched = new GlideSchedule(gr.sys_id); var gdt = new GlideDateTime(); if (sched.isInSchedule(gdt)) { // Scheduled job logic goes here } If you didn't set the time zone field in the schedule [cmn_schedule] record, the scheduled job will assume that the time entries are defined in the system time zone, not your local time (e.g. 11AM Pacific Time instead of 11AM GMT). For the most simple use cases, you could also decompose the calendar record into multiple calendars, each with only one time entry per day, and associate each new calendar to a copy of the scheduled job record. For example, for a calendar with two time entries on Monday, 9-9:30AM and 10-10:30AM, you could create two calendars with just a single time entry on Monday and assign each one to a copy of the same scheduled job. However, this leads to duplication of scheduled job records and prolonged use of the deprecated calendar functionality, so it is not recommended.