Why ServiceNow Schedule Calendars Suddenly Stop Working (Even Without Role Changes)

A user reports:

"Last month I could open the Schedule Calendar using 'Show Schedule,' but now I get a Security constraints prevent access message."

No role changes. No group changes. No recent deployments touching On-Call. Yet the calendar suddenly becomes inaccessible.

This scenario is far more common than it appears, and it usually isn't a defect. It's a data-level permission shift — a silent change that occurs underneath the roles and groups. Let's break it down.

1. Schedule access isn't controlled only by roles

Many ServiceNow users assume:

"If I'm in the right group and have on-call roles, I can access the schedule."

But schedule access depends on ownership and underlying ACLs, especially on these tables:

• cmn_schedule — the base schedule record
• cmn_rota — the on-call shift record layered on top of a schedule
• cmn_schedule_span and, for On-Call Scheduling specifically, roster_schedule_span — the individual time spans that make up the calendar view

If the owner group, schedule, or rota visibility shifts — even slightly — a user may lose access without any admin touching their roles.

Typical causes

• Schedule ownership changed to a group the user is no longer part of
• Rota owner field updated accidentally
• A new ACL was introduced by another team or plugin
• A schedule was copied from another environment with different permissions

2. "Show Schedule" loads a calendar UI page — and that page enforces ACLs

The "Show Schedule" link loads a specific UI Page that visually renders the calendar. This page queries schedule records, loads rota and span data, and renders only what the user is allowed to see.

If the user fails even one ACL check on any related record (for example, a span they cannot read), the entire page can fail with:

Security constraints prevent access to requested page

Even though the user has the same roles and the same group membership, they can still fail an ACL evaluation because the data they're trying to view is now restricted.

3. Why it "used to work" and now it doesn't

This is the most confusing part for users. It happens because someone changed the schedule's group, the rota's owner, a span record's permissions, or a schedule was overwritten or reimported — or a Dev → Test → Prod migration created mismatched access.

These changes often happen silently:

• A rota owner edits the group
• Another support team updates a schedule
• Copy changes from one environment alter ownership
• A plugin update modifies ACL inheritance

No code change. No role change. But access breaks.

4. The quickest way to diagnose the issue (admin steps)

Step 1 — Test as the impacted user (Impersonate). Try to open the group, the on-call schedule, the specific rota, and the calendar UI page. Find what fails.

Step 2 — Check these ACLs. Review read ACLs on cmn_schedule, cmn_rota, and cmn_schedule_span (or roster_schedule_span if On-Call Scheduling is active). If any "read" ACL denies access, the calendar collapses completely.

Step 3 — Confirm schedule ownership. Check Schedule → Group, Rota → Group, and Coverage/Span → Owned by which group. If ownership belongs to a private group the user cannot see, the calendar stops loading.

5. How to prevent this issue in the future

• Lock schedule ownership. Assign a single designated owner group for on-call schedules and restrict edit access.
• Prevent accidental schedule overwrites. If teams import or export schedules across environments, enforce update sets with fixed ownership and restrict access to schedule tables.
• Build a diagnostic report that flags schedules owned by private groups, rota records with mismatched permissions, and spans that belong to inconsistent groups.
• Add a knowledge article for end users so that instead of panic escalations, they understand what the error means, why it occurs, and how to request access properly.

Conclusion

When "Show Schedule" suddenly stops working, it's rarely a defect — it's usually data-level permission drift. The underlying tables powering on-call scheduling are sensitive to ownership and group visibility, and even a small shift can break the UI page.

With controlled ownership, regular audits, and a simple access troubleshooting checklist, this becomes a preventable issue.

---

Table and field names referenced here reflect the base Common Schedule and On-Call Scheduling data model. Exact ACL configuration and inherited access rules can vary by instance, active plugins, and customizations — verify against your own instance before making ACL changes.