Assigner
How it works Pricing Demo Blog FAQ Contact Sign in
Use case

ServiceNow On-Call Scheduling: On-Call Schedule, Escalation Trigger Rules, and Assign by Acknowledgement

On-Call Scheduling decides who gets paged, not who owns the work. Its trigger rules fire only on specific create and update conditions, its escalation cancels when the group changes, and an incident that arrives with nobody acknowledging keeps an empty Assigned to field until a human notices. This page lays out how the module actually assigns, where it leaks, and where an assignment engine fits beside it.

See how it works
Rules you control Works beside your stack No black box No sales call
Routing Studio
Assigned

✓Routed by your rules
Inbox
Assignees load
Skipped

In short

ServiceNow On-Call Scheduling finds the on-call member of a support group by rotating through a hierarchy of duty rosters, then assigns and notifies them through a trigger rule when a task is created or updated. Schedules rotate daily, weekly or monthly, rosters escalate primary to secondary to a catch-all, and notifications go by SMS, voice, push, Slack or Teams. It ships with the ITSM plugin com.snc.on_call_rotation at no separate cost. It does not balance load, and incidents that no one acknowledges or that arrive with a group already set can stay unowned.

// THE FIT

Why it fits

This page is for an IT operations manager, major incident manager or ServiceNow admin running On-Call Scheduling for support groups, whose critical incidents sometimes page nobody, sit unowned overnight, or land on the same engineer every time, and who needs every incident assigned to an available person with a recorded reason.

A group written first switches the trigger rule off

A ServiceNow employee put it plainly in a community thread: assignment rules do not run if the group is automatically filled in, and that impacts trigger rules as well. An inbound action, a record producer or a template that sets the assignment group before the rule evaluates means the on-call person is never assigned or paged, and nothing logs the skip.

After-hours incidents keep an empty Assigned to

When the escalation runs out without an acknowledgement, the incident sits with its group and no owner. Nothing re-runs the assignment in the morning. Community admins write scheduled jobs that search for incidents with a group and no assignee just to find them.

Changing the group cancels the escalation

The documentation states that an on-call escalation is canceled when the assignment group changes to a different group without a matching trigger rule. A service desk agent who moves a P1 to the right team can silently stop the page that was already running.

A priority raised later may never page anyone

Trigger rules run once by default. An incident logged at priority 3 and raised to priority 1 an hour later does not start on-call unless the rule is set to run every time the trigger field changes, which is an option on the form that most setups leave off.

Schedule times follow the admin who built them

The docs say the logged-in user time zone is the basis for schedules, falling back to the instance time zone. A rota built by an admin in Chicago for a team in London starts and ends shifts in the wrong hour until someone notices the first missed page.

It pages one person and balances nothing

On-Call answers who is on duty right now. It does not count how many incidents that person already holds, does not rotate daytime work across the group, and does not record why one engineer got the ticket instead of another. That is a separate problem from paging.

// COMPARE

Side by side

How On-Call Scheduling assigns an incident, step by step, and where each step leaks

Step What the platform does Configured in Skipped or stalls when What you see
Trigger rule Matches a created or updated task, for example Critical or High assigned to Network, and runs a subflow On-Call Scheduling, Trigger Rules (rota_admin, rota_manager) The group was already set by another process, or the rule runs once and the priority changed later Incident has a group, no assignee, no page
Assign or Assign and Notify subflow Writes the current on-call member into Assigned to and notifies them Trigger rule action No active shift covers the current time, or the schedule was never published Nobody assigned, no error
Assign By Acknowledgement Notifies in order and assigns whoever acknowledges first Trigger rule action Nobody acknowledges before the catch-all Incident waits unowned after the last level
Escalation through rosters Primary, then secondary, then further rosters by escalation delay Schedule, Escalation Policy Assignment group changes to a group without a matching trigger rule Escalation canceled mid-flight
Catch-all Notifies a group manager, shift manager, an individual, or all roster members Schedule, Catch-all field Catch-all set to none Page stops at the last roster
Time off and cover Member requests time off and names a colleague to cover Rota manager approval Time off approved with no cover A gap in the Gaps and Conflicts report

Trigger rules can run a subflow (Assign, Assign and Notify, Assign By Acknowledgement, Escalations by Email), a workflow, or a script; the script option is limited to rota_admin and admin. Rotation is daily, weekly or monthly, and the documentation advises against monthly or yearly shifts.

// DETAIL

In detail

What the ServiceNow documentation and community actually say about On-Call Scheduling

How ServiceNow On-Call Scheduling assigns an incident

The documentation describes the module in one line: it identifies the assigned and available member of a support group, for example when assigning an incident, by rotating through a hierarchy of duty rosters. The mechanics sit in three records that must be built in order, which a ServiceNow community setup guide spells out as Schedule, then Trigger Rule, then Escalation Policy.

The schedule defines the rosters and rotation (daily, weekly or monthly) and the escalation type: Rotate Through Members for one roster or Rotate Through Rosters for several. The trigger rule is checked when a task is created or updated. The documented example is exact: if an incident with level Critical or High is raised and is assigned to the Network group, run the Assign and Notify workflow. The escalation policy then decides who hears about it next when the first person does not respond.

The plugin is com.snc.on_call_rotation, and the data lives in cmn_rota (the schedule), cmn_rota_roster and cmn_rota_member. Scripts reach it through the OnCallRotation API, including getEscalatees() and whoIsOnCall.

Why the trigger rule never fires on some incidents

The single most common complaint is an incident that should have paged someone and did not. The cause is usually upstream. A ServiceNow employee answered a thread titled On-call trigger rules and assignment group issue with the line that explains most of them: assignment rules do not run if the group is automatically filled in, so this does impact trigger rules as well. An email inbound action, a catalog record producer, an Event Management rule or a template that writes the assignment group before the trigger rule evaluates removes the incident from on-call entirely.

The workaround in that thread was a business rule that fires an event to start the on-call flow explicitly. The better fix is to decide which process owns the assignment group and make every other process leave it empty. Two more documented behaviors produce the same symptom. Trigger rules run once by default, so a priority raised after creation does not page unless the rule is set to Every time trigger field changes. And an escalation that is already running is canceled when the assignment group changes to a different group without a matching trigger rule.

Why after-hours incidents sit unassigned until morning

When the last roster does not acknowledge, the escalation ends at the catch-all. The catch-all can be none, a group manager, a shift manager, an individual, or any or all roster members. If it is none, the page simply stops. Either way, the incident keeps its assignment group and an empty Assigned to, and nothing revisits it.

Admins in the community write a scheduled job that queries incidents where the group is set and the assignee is empty, just to surface them at the start of the day. That is a sign of the design: On-Call is a notification chain, and when the chain ends the work has no owner. A ServiceNow blog on major incident on-call adds the operational version: forgetting to publish the schedule is the number one reason pilots fail, because an unpublished schedule assigns nobody and shows no error.

Gaps, conflicts, time off and time zones

The Gaps and Conflicts report is the health check. A gap is time off scheduled with no one covering, a member removed from the group, or a member marked inactive. A conflict is a user assigned as both primary and secondary contact for the same shift. Roster members can request time off and name a colleague to cover, and the rota manager approves it; an approved request with no cover becomes a gap.

Time zones are the quieter trap. The documentation states that the logged-in user time zone is the basis for schedules, and the instance time zone is used when the user has none. Build a follow-the-sun rota from one admin account and every shift boundary is set in that admin hour. Overlapping rotas were not supported in older releases, where whoIsOnCall returned a single rota, and getEscalatees() returns an empty list if no shift is active at the moment the script runs.

On-Call Scheduling roles and license

Configuration needs rota_admin; rota_manager approves time off and resolves gaps for the groups they manage; trigger rules can be created by rota_admin, admin or rota_manager. Recent release notes add an oc_read role for read-only access and turn escalation logging on by default.

On licensing: under legacy ITSM packaging the plugin was included with ITSM, and a ServiceNow employee described it as a free plugin. Under the April 2026 packaging, a community licensing summary lists On-Call inside ITSM Advanced, not Foundation. The full breakdown, including PagerDuty and Opsgenie comparisons, is in our ServiceNow On-Call Scheduling license guide.

Where Assigner fits beside On-Call Scheduling, and where it does not

If your problem is waking the right engineer at 3 am, keep On-Call Scheduling or a paging tool; Assigner does not replace a pager, and it does not place voice calls. The problems On-Call does not solve are the daytime and the handoff. It pages one person and does not count what they already hold, so the engineer who is on call all week also collects every daytime incident. It does not rotate the non-urgent queue across the group. And when the chain ends, the work has no owner and no record of why.

Assigner sits beside ServiceNow and decides the owner for each incident, task or request by round robin, weighted rotation, current load, skills and working hours, skipping people who are out, and it writes the rule and reason on every assignment. On-Call keeps doing what it is good at: paging a human for the critical few. Assigner is $12 per user per month billed yearly ($15 billed monthly), and the rules stay yours.

// FAQ

Questions buyers ask

Frequently asked questions

What is On-Call Scheduling in ServiceNow?

It is the ServiceNow module that identifies the assigned and available member of a support group, for example when assigning an incident, by rotating through a hierarchy of duty rosters. It combines schedules, rosters, trigger rules and escalation policies, and notifies people by SMS, voice, mobile push, Slack or Microsoft Teams.

How do I set up an on-call schedule in ServiceNow?

Build it in order: create the schedule for the group with its rosters, members and rotation, then a trigger rule that decides which tasks start on-call, then the escalation policy. Publish the schedule when it is ready; a ServiceNow blog names forgetting to publish as the most common reason pilots fail. Check the Gaps and Conflicts report before go live.

What are escalation trigger rules in ServiceNow On-Call Scheduling?

They are the conditions that start on-call for a task, checked when the task is created or updated. The documented example runs the Assign and Notify workflow when a Critical or High incident is assigned to the Network group. A rule runs once or every time the trigger field changes, and its action can be a subflow, a workflow or a script.

What is assign by acknowledgement in ServiceNow On-Call?

Assign By Acknowledgement is one of the trigger rule subflows. It notifies the on-call contacts in escalation order and assigns the task to whoever acknowledges first, by email, SMS or voice. If nobody acknowledges before the catch-all, the task keeps its group with no assignee.

What roles are needed for ServiceNow On-Call Scheduling?

rota_admin configures schedules, rosters and trigger rules. rota_manager approves time off and resolves gaps for the groups they manage and can create trigger rules. admin can do everything. Newer releases add oc_read for read-only access. The script action on a trigger rule is restricted to rota_admin and admin.

Which tables does ServiceNow On-Call Scheduling use?

The core tables are cmn_rota for the schedule, cmn_rota_roster for rosters, and cmn_rota_member for roster members. Scripts read them through the OnCallRotation API, for example getEscalatees() and whoIsOnCall, rather than querying the tables directly.

Why is my ServiceNow on-call trigger rule not firing?

Usually because the assignment group was set by another process before the rule evaluated; a ServiceNow employee confirmed that trigger rules do not run when the group is filled in automatically. Also check that the rule runs every time the trigger field changes if priority is raised later, that the schedule is published, and that a shift is active.

What happens when nobody acknowledges an on-call escalation?

The escalation moves through the rosters and ends at the catch-all, which can be none, a group manager, a shift manager, an individual or all roster members. After that the task keeps its group and an empty Assigned to. Many teams run a scheduled report for incidents with a group and no assignee to catch them.

Does ServiceNow On-Call Scheduling handle time off?

Yes. Roster members submit a time-off request and can name another member to cover the shift, and the rota manager approves it. Time off approved with no cover shows up as a gap in the Gaps and Conflicts report, and the on-call lookup will return nobody for that window.

What time zone does a ServiceNow on-call schedule use?

The logged-in user time zone of the person creating the schedule, falling back to the instance time zone if that user has none. Global teams should build each regional schedule from an account set to that region, or check every shift boundary after import.

Is ServiceNow On-Call Scheduling licensed separately?

No separate SKU turned up in our research. Under legacy packaging it came with ITSM, and a ServiceNow employee described it as a free plugin. A community summary of the April 2026 packaging lists On-Call in ITSM Advanced rather than Foundation, so confirm with your account team if you are on Foundation.

Can ServiceNow On-Call balance incidents across the team?

No. It finds who is on duty now and notifies them; it does not count how many open incidents that person holds or rotate daytime work across the group. Load-aware rotation needs Advanced Work Assignment, custom scripting, or a routing layer beside ServiceNow such as Assigner.

Keep reading

Related ServiceNow routing pages worth reading next:

Stop hand-sorting your incoming work

Let Assigner route it to the right available person by skill, workload, and availability, using rules you control. Nothing sits unassigned and no one gets cherry-picked. Every assignment shows why.