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

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.

How to Generate the Correct OneDrive OAuth Token in ServiceNow

If your ServiceNow instance keeps uploading files into the wrong OneDrive folder, it means the OAuth token was issued for the wrong Microsoft account. This is the exact procedure to generate a correct token for the right service account, using a manually configured OAuth Application Registry — the approach behind a custom-built OneDrive integration rather than ServiceNow's official OneDrive Spoke.

A note on scope before starting: this procedure applies specifically to a custom OAuth setup built around a System OAuth Application Registry entry, which relies on the delegated permissions model — the same mechanics covered in this blog's companion articles on why ServiceNow needs two Microsoft identities, and why uploads land in the wrong folder in the first place. If your integration instead runs through ServiceNow's official Microsoft OneDrive Spoke, authentication is typically managed through its own Connection & Credential Alias — often set up with a certificate-based application identity rather than a delegated user session — and this specific token-regeneration procedure won't apply the same way. Confirm which of the two you're actually running before following the steps below.

Prerequisites

• OneDrive service account
• Azure AD (Entra ID) admin account, for App Registration
• OneDrive OAuth profile configured in ServiceNow
• Valid Client ID and Client Secret

Why This Procedure Is Necessary

With SSO environments:

• VDI login automatically logs users into Microsoft.
• Teams/Outlook auto-start with cached credentials.
• Office apps silently authenticate.

This means clicking Get OAuth Token will always use whatever Microsoft session is active — even if you logged into ServiceNow with a different account.

Step-by-Step Procedure

Step 1 — Completely Log Out of All Microsoft Sessions

You must remove all cached Microsoft identity data:

• Sign out of Teams.
• Sign out of Outlook.
• Stop the OneDrive sync client.
• Close Office apps.
• Log out of Office.com.
• Clear browser cookies.
• Restart the browser.
• Optionally, reboot the VDI session.

Step 2 — Open a New Incognito Window

Do not use a normal window — normal windows share cookies from the VDI session you just tried to clear.

Step 3 — Sign In to Microsoft Manually With the OneDrive Account

In the incognito window:

• Go to https://login.microsoftonline.com.
• Sign in as the OneDrive service account.
• Complete MFA if required.

At this stage, Microsoft knows the identity that should receive the OAuth token.

Step 4 — Log In to ServiceNow With the Same Service Account

Still in the same incognito window:

• Log in to ServiceNow as the OneDrive service account.
• Do not use impersonation — impersonation only changes the ServiceNow-side identity, not the Microsoft session behind it.

Step 5 — Navigate to the OneDrive OAuth Profile

Go to:

System OAuth → Application Registry → Your OneDrive OAuth Profile

Step 6 — Click "Get OAuth Token"

This time:

• Microsoft sees the OneDrive service account as the active session.
• Microsoft issues the OAuth token for the OneDrive service account.
• ServiceNow stores the token under the OneDrive service account's user context.

Step 7 — Validate the Token

Run a test action against your configured OneDrive integration — for example, a Create Folder action. The folder should appear under the OneDrive service account's OneDrive path, not any other account's.

What If It Still Shows the Wrong Account?

Then the VDI or OS-level Microsoft session is still active. Use one of these options:

• Try a different browser.
• Use an entirely different machine.
• Use a private Windows account profile.
• Disable Teams auto-login temporarily.
• Use a clean VM with no corporate SSO session.

Once the correct token is captured, normal usage will no longer rely on the end user's Microsoft session — the token, once correctly issued, stays valid independent of whoever's logged into Windows or Teams afterward.

If You're Doing This Often, Consider the Structural Fix

This procedure works, but it's worth being honest about what it actually is: a careful manual workaround for a session-dependent authentication model. If this keeps recurring — a token needs regenerating every time someone's VDI session changes, or every time a service account's cached credentials expire — that's a signal worth acting on, not just repeating the fix for. Moving to ServiceNow's official Microsoft OneDrive Spoke, configured with a certificate-based application identity rather than delegated permissions, removes the session dependency at its root. See this blog's companion article on wrong-folder uploads for the specific setup details, including the Sites.Selected scoping option that keeps the application's access appropriately limited rather than organization-wide.

Summary

To ensure ServiceNow writes files into the correct OneDrive folder:

• The OneDrive service account must be the active Microsoft identity when generating the OAuth token.
• Logging in to ServiceNow as that same service account ensures correct token storage.
• Clearing cached Microsoft sessions is essential in SSO environments.

Following these steps guarantees the OAuth token belongs to the correct storage account every time — and if you find yourself following them often, that's the cue to look at the Spoke-based alternative instead of treating this as a permanent routine.