What This Table Is

The cmn_schedule table defines work schedules that control when business processes operate. It stores the metadata for schedules — names, time zones, descriptions — while the actual time spans live in cmn_schedule_span and cmn_other_schedule. These schedules drive SLA calculations, determine when Business Rules should fire, and control maintenance window timing.

This table belongs to the Platform module and supports every process that needs to understand "business hours." The Service Level Management plugin heavily depends on schedules for SLA calculations, while Change Management uses them to control when changes can be deployed. On-call schedules for incident response also reference this table.

The cmn_schedule table doesn't extend another table — it's a base table. No tables extend it either, but several tables reference it: contract_sla, sys_user_group, and cmn_cost_center all have schedule reference fields.

Most instances have 10-50 schedule records, making this a low-volume table. Performance is rarely an issue when querying schedules directly, but the related span tables can get large with complex rotating schedules. Enterprise instances with multiple business units often have 20+ schedules covering different time zones and business patterns.

When You'll Script Against This Table

You'll query cmn_schedule in Business Rules that need to check if current time falls within business hours, Script Includes that calculate SLA due dates, and Scheduled Script Executions that should only run during maintenance windows. The GlideSchedule API handles most schedule calculations, but you still need to query this table to get the schedule sys_id first.

All users can read schedule records by default — there's no restrictive ACL. The admin role is required to create or modify schedules. Schedule-related Business Rules run in the system context and don't hit permission issues.

Common scripting patterns:

  • Look up a schedule by name to get its sys_id for GlideSchedule API calls
  • Check if the current user's group has an assigned work schedule
  • Filter active schedules by time zone for multi-region deployments
  • Create schedule references on new SLA definition records
  • Build schedule selection lists for UI customizations
  • Validate schedule references before SLA calculations
  • Copy schedule settings when cloning business processes

Table Gotchas

⚠️

Schedule records without spans in `cmn_schedule_span` appear as "24x7" schedules to the GlideSchedule API, which breaks most business hour logic. Always verify spans exist.

⚠️

The `time_zone` field stores time zone names that don't match JavaScript standard names. Use GlideSchedule methods instead of trying to convert manually.

  • The type field looks like a choice field but it's actually a string. Values include "weekly", "monthly", and "exclude_spans" — not documented in choice lists.
  • Inactive schedules (active=false) still work in GlideSchedule API calls. The active flag only affects UI visibility, not schedule calculations.
⚠️

Deleting a schedule referenced by active SLA definitions causes SLA workflow errors. Check `contract_sla.schedule` references before deletion.

  • The name field allows duplicates, which breaks schedule lookup scripts that assume unique names. Always query by sys_id when possible.
  • Performance trap: joining to cmn_schedule_span in GlideRecord queries can be slow on complex rotating schedules. Use GlideSchedule API instead.
Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime

Related Tables

The cmn_schedule_span table stores the actual time periods that define when a schedule is active. Every useful schedule has multiple span records that define daily hours, days of week, or specific date ranges. The cmn_other_schedule table handles exclusions — holidays and maintenance windows that override the normal schedule spans.

The most common joins involve contract_sla (SLA definitions reference schedules for business hour calculations), sys_user_group (groups can have work schedules for assignment logic), and cmn_cost_center (cost centers track business hours for financial reporting). You'll also see schedule references in custom tables that need business hour logic.

When building reports or dashboards around SLA performance, you'll frequently query schedules alongside task_sla records to understand how business hours affect SLA calculations. The sys_calendar table also connects to schedules for holiday and blackout date handling.