What This Table Is

The cmn_rota table stores on-call rotation definitions that determine which groups or individuals are responsible for handling incidents during specific time periods. Each record represents a complete rotation schedule with defined members, time slots, and escalation rules. The table powers ServiceNow's incident routing engine by providing real-time lookup of who should receive assignments based on current time and rotation state.

Owned by the ITSM module, this table integrates directly with incident management workflows, escalation rules, and assignment rules. The platform queries cmn_rota records during incident creation and escalation to determine proper routing paths. Rotation schedules can span weeks or months with complex patterns including holidays, shift changes, and backup coverage.

This table does not extend any parent table but works closely with cmn_rota_member (individual rotation participants) and cmn_rota_roster (specific time slot assignments). The relationship forms a hierarchy where a single rota contains multiple members who are assigned to specific roster time slots.

Enterprise implementations typically maintain 10-50 active rotation records with each supporting 5-20 members across multiple time zones. Query performance remains strong due to the relatively small record volume, but complex rotation calculations can impact response time during peak incident periods when multiple escalation rules execute simultaneously.

When You'll Script Against This Table

Developers query cmn_rota primarily in Business Rules triggered by incident escalation, Script Includes that handle assignment logic, and Scheduled Jobs that maintain rotation state. Custom assignment engines and escalation workflows rely heavily on this table to resolve current on-call assignments. Access requires itil role permissions with additional rota_admin role needed for modification operations.

Integration scenarios frequently involve custom web services that need to identify current on-call personnel for external monitoring tools, or reporting scripts that analyze rotation coverage and member workload distribution across time periods.

Common scripting patterns:

  • Query active rotations by group reference for incident assignment logic
  • Calculate current on-call member using rotation start date and member sequence
  • Validate rotation schedule overlaps and gaps during rota configuration
  • Generate rotation reports showing member assignment history and upcoming shifts
  • Synchronize external on-call systems with ServiceNow rotation schedules
  • Implement custom rotation types beyond standard weekly patterns
  • Build escalation matrices that traverse multiple related rotation schedules

Table Gotchas

⚠️

The 'state' field uses choice values ('active', 'inactive') but inactive rotations still appear in queries unless explicitly filtered. Always check state in assignment logic.

⚠️

Rotation start dates (start_date_time) must align with roster patterns or current member calculations will be incorrect. Off-by-one errors are common.

  • The rotation_interval_count field works with rotation_interval_type but doesn't validate logical combinations—you can create impossible schedules like 0-day rotations
  • Time zone handling in time_zone affects all date calculations but doesn't automatically adjust for daylight saving time transitions
⚠️

Deleting rota records breaks historical assignment tracking. Use state='inactive' instead to preserve incident audit trails.

  • The group reference field allows null values but most assignment logic assumes it's populated, causing null pointer exceptions
  • Performance degrades when querying rotations with large member counts during peak hours—consider caching current assignments in custom tables
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_rota_member table stores individual participants in each rotation, while cmn_rota_roster contains specific time slot assignments. These three tables form the complete rotation framework, with cmn_rota as the parent definition. Most rotation queries require joining all three tables to resolve current assignments.

The sys_user_group table links rotations to assignment groups for incident routing, while sys_user provides member details and contact information. Assignment rules in sys_assignment frequently reference rota records to implement dynamic assignment based on current on-call status.

Incident records in the incident table often store the assigned rota reference for audit purposes, and escalation rules in sys_escalation use rota queries to determine next-level assignment targets during incident progression.