Why ServiceNow Schedule Calendars Fail Unexpectedly
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 Is Not 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_rota
-
cmn_schedule
-
cmn_schedule_span
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” Redirects to a Calendar UI Page — and That Page Enforces ACLs
The “Show Schedule” link loads a specific UI Page or UI Script that visually renders the calendar.
This page:
-
Queries schedule records
-
Loads rota and span data
-
Renders only what the user is allowed to see
If the user fails even one ACL check on any related record (e.g., 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
-
Has 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.
Because someone changed:
-
The schedule’s group
-
The rota’s owner
-
Span records’ permissions
-
A schedule was overwritten or reimported
-
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
-
the calendar UI Page
Find what fails.
Step 2 — Check these ACLs
Tables to review:
-
cmn_schedule
-
cmn_rota
-
cmn_schedule_span
If any "read" ACL denies access → the calendar collapses completely.
Step 3 — Confirm schedule ownership
Check:
-
Schedule → Group
-
Rota → Group
-
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
A. Lock schedule ownership
Assign a single designated owner group for on-call schedules.
Restrict edit access.
B. Prevent accidental schedule overwrites
If teams import/export schedules across environments, enforce:
-
Update sets with fixed ownership
-
Restricted access to schedule tables
C. Build a diagnostic report
A simple report can flag:
-
Schedules owned by private groups
-
Rota records with mismatched permissions
-
Spans that belong to inconsistent groups
D. Add a Knowledge Article for end-users
Instead of panic escalations, users understand:
-
What the error means
-
Why it occurs
-
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.
0 comments:
Post a Comment