Why Out-of-Box Features Suddenly seems broken in ServiceNow?

Many ServiceNow administrators have seen a familiar problem: an out-of-box (OOB) feature that worked perfectly for months suddenly stops functioning for certain users. Although nothing changed in the user’s roles or group membership, the platform starts throwing errors such as “Security constraints prevent access.”

This article explains why this happens, what the hidden triggers are, and how to systematically diagnose and resolve these issues using proven techniques.

---

1. OOB Does Not Mean Static — ServiceNow Changes Behind the Scenes

A common misconception is that OOB features remain stable if administrators don’t modify them. In reality, ServiceNow routinely releases:

• security patches

• platform updates

• ACL improvements

• UI page updates

• reference qualifier fixes

Any of these can inadvertently tighten access to an OOB feature.

Real example:

The “Show Schedule” calendar worked last month. After a platform security update, the ACL on the underlying cmn_schedule_calendar table began enforcing stricter group access. Users now see an access error.

---

2. Data-Level Permissions Matter More Than People Realize

Even if roles haven’t changed, the data they are trying to access may have changed.

In ServiceNow, record visibility is impacted by:

• Group ownership

• Reference qualifiers

• Domain separation

• Table ACLs

• Field ACLs

• Record ACL scripts

For example, if a schedule record is owned by a group the user can no longer see, the calendar widget will fail—even though the user technically has the right roles.

Common data-level causes:

• The schedule was reassigned to a different group

• The group was renamed or deactivated

• User’s group membership changed indirectly (via AD sync)

• Domain was changed (intentional or accidental)

---

3. Reference Qualifiers Can Suddenly Exclude the Record

Many OOB widgets rely on reference qualifiers or filter conditions.
If those qualifiers begin enforcing updated logic (due to a patch or dictionary change), the record previously visible may now be excluded.

Example:

javascript: gs.getUser().isMemberOf(current.group)

If the user is no longer a member, the calendar lookup silently fails.

---

4. Security Patches Tighten ACL Behavior

ServiceNow frequently enhances ACL evaluation logic for security hardening.

Before:
A permissive or faulty ACL script quietly allowed access.

After patch:
The script now enforces strict evaluation → user loses access.

This is one of the most common causes behind sudden OOB access failures.

---

5. UI Page or Script Includes May Have Role Requirements

Even if a table ACL allows access, the UI Page rendering the calendar or widget may have:

• a role restriction

• a new script

• a changed include

• a new dependency on a secured API

A small unnoticed update can break the entire page for certain users.

---

6. How to Diagnose the Issue Quickly

Step 1 — Impersonate the User

Try to open the same record or page.

Step 2 — Enable Debug Security

Navigate to:
System Diagnostics → Debug Security

Then reproduce the error.
This will show exactly which ACL is blocking access.

Step 3 — Inspect the Schedule or Data Record

Check:

• group field

• ownership

• domain

• active status

• visibility through reference selectors

Step 4 — Review Platform Update History

Check:

• System Logs → Update Sets

• Plugin activations

• Patch history

• Scripts updated recently

Step 5 — Test with an Admin

If even admin struggles to open certain pages, the issue is UI-page related—not ACL related.

---

7. Preventing Future OOB Access Breakages

• Regularly review ACL scripts after platform upgrades

• Use ATF to validate critical workflows after patching

• Avoid depending on ACL scripts that reference specific users/groups

• Maintain good documentation of group ownership for key business objects

• Monitor the update history of all “show schedule”, “calendar”, or other UI pages

---

Conclusion

OOB features in ServiceNow can break even without visible configuration changes. The interplay of ACLs, data-level permissions, group ownership, reference qualifiers, and platform patches makes access an evolving landscape.

The key is recognizing that “nothing changed” is rarely accurate — something did change, even if indirectly.
By following a systematic debugging approach and understanding how access is evaluated, admins can resolve issues quickly and prevent unnecessary escalations or panic incidents.

Read More

Ultimate Troubleshooting Guide: Fixing ServiceNow + OneDrive OAuth, Token, and Folder Path Issues

Ultimate Troubleshooting Guide: Fixing ServiceNow + OneDrive OAuth & Folder Path Issues

ServiceNow’s integration with Microsoft OneDrive often works flawlessly—until it doesn’t.
Admins frequently see issues like:

• Files uploaded into the wrong user’s OneDrive folder

• Tokens regenerating but not applying properly

• “OAuth access or refresh token not available”

• OneDrive Spoke actions failing silently

• No prompt for Microsoft login when clicking Get OAuth Token

This troubleshooting guide gives you precise workflows to identify and resolve root causes.

1. Verify You Are Using the Right OAuth Profile

Go to:

System OAuth → Application Registry

Confirm that:

✔ Only one OneDrive OAuth application exists
✔ Its Client ID matches Azure App Registration
✔ Its Client Secret is valid
✔ Grant Type = Authorization Code (required for OneDrive Spoke)

If there are duplicate profiles → delete or deactivate the unused ones.

2. Confirm You Are Clicking “Get OAuth Token” Under the Correct Credential

Navigate to:

Connections & Credentials → Credentials → (Your OneDrive Spoke Credential)

Then:

✔ Ensure this credential uses the same OAuth profile
✔ Ensure your connection record uses this credential
✔ Click Get OAuth Token only after logging in with the correct Microsoft user

3. Verify Microsoft Session Identity (THE #1 FAILURE POINT)

Go to https://myaccount.microsoft.com and confirm:

✔ Who is currently logged in?
✔ Is Teams logged in?
✔ Is Outlook logged in?
✔ Is OneDrive sync client logged in?

Incorrect account = incorrect OAuth token.

4. Fix Token Ownership: Generate Token for the Right OneDrive Account

To issue the correct token:

1. Sign out from all Microsoft apps

2. Clear browser cookies + cache

3. Open a new incognito window

4. Sign in to Microsoft as the intended OneDrive service account

5. Log in to ServiceNow as the same account

6. Click Get OAuth Token

If it still uses the wrong account:
– Use a different browser
– Use a clean VM
– Use a private Windows profile
– Disable “Windows Account Manager” in Edge settings

5. Test OneDrive Spoke Connectivity

Test using:

OneDrive → List Drive Items

✔ If results come from the wrong drive → wrong token
✔ If unauthorized → wrong permissions
✔ If empty → token is correct but folder path is wrong

6. Validate Graph Permissions

Your Azure App Registration must include:

Delegated permissions:

• Files.ReadWrite.All

• Files.Read.All

• User.Read

• offline_access

And admin consent must be granted:

Azure portal → App Registration → API Permissions → Grant admin consent

If consent is missing, tokens will work but operations silently fail.

7. Confirm the OneDrive Service Account Actually Has OneDrive Enabled

Go to the Microsoft Admin Center:

✔ The account must have a valid OneDrive license
✔ It must have logged in to OneDrive at least once
✔ Storage must be provisioned

If not, OneDrive Spoke will fail with misleading errors.

8. Check Whether the Token Belongs to the Wrong User in ServiceNow

Find token owner:

sys_oauth_credential.do

Look at the field:

Authorized by User

If this shows Hoff, admin, or any user except your service account → wrong identity is issuing the token.

9. Verify the Document Path Logic in ServiceNow

For Document Services:

Navigate to:

Document Management → Connection Configuration → OneDrive Settings

Check:

✔ Default folder
✔ Path variable mapping
✔ Whether a user-specific folder is enforced
✔ Whether the integration uses SharePoint or personal OneDrive

10. Reset Token If Needed

If things are completely broken:

1. Remove OAuth tokens from sys_oauth_credential

2. Remove token from OneDrive Spoke credential

3. Restart token flow (following Step 4)

Summary Checklist

Issue	Likely Cause
Files going to wrong OneDrive user	Microsoft session mismatch
No Microsoft login prompt	SSO or cached session
OAuth token unavailable	Client secret mismatch / expired token
OneDrive Spoke failing	Missing Graph permissions
Token stored under wrong ServiceNow user	Wrong login identity during OAuth
Files uploading but not into correct path	Incorrect folder mapping

Read More

How to Generate the Correct OneDrive OAuth Token in ServiceNow

How to Correctly Generate the 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.

Here is the exact procedure to generate a correct token for the right service account.

Prerequisites

• OneDrive service account

• Azure AD 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 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.

STEP 3 — Sign in to Microsoft manually with the OneDrive account

In the incognito window:

• Go to https://login.microsoftonline.com

• Sign in as 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 OneDrive service account

• Do NOT use impersonation

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 OneDrive service account as the active session

• Microsoft issues the OAuth token for OneDrive service account

• ServiceNow stores the token under the OneDrive service account user context

STEP 7 — Validate the Token

Run a simple OneDrive Spoke action:

OneDrive → Create Folder

The folder should appear under OneDrive service account’s OneDrive path.

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.

Summary

To ensure ServiceNow writes files into the correct OneDrive folder:

• The OneDrive service account must be the Microsoft identity when generating the OAuth token

• Logging in to ServiceNow as that 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.

Read More

ServiceNow + OneDrive OAuth Tokens: Why Files Keep Uploading to the Wrong User’s Folder

Why ServiceNow Uploads Documents to the Wrong OneDrive Folder — And How to Fix It

Many ServiceNow teams experience a confusing issue:

“We clicked Get OAuth Token, but files upload to the wrong user’s OneDrive folder.”

This happens even when logged in as a different ServiceNow user or when impersonating.
The root cause is not in ServiceNow at all—it’s in Microsoft session handling.

Let’s explain.

1. OAuth Token Is Issued to the Active Microsoft Session

When you click Get OAuth Token in ServiceNow:

• ServiceNow triggers an OAuth flow

• Microsoft checks who is currently signed in

• Microsoft issues an OAuth token for that account

• ServiceNow stores that token under the user record

Therefore, ServiceNow is simply the redirect channel.
Microsoft chooses the identity.

2. VDI / SSO / Teams Auto-login Makes This Worse

Many enterprise users log into a VDI or laptop using SSO, causing Microsoft apps like:

• Teams

• Outlook

• Office.com

• OneDrive client

…to automatically authenticate using a personal or admin account.

This means:

• Even if you open an Incognito window

• Even if you log in to ServiceNow as a different user

• Even if you impersonate

Microsoft will still issue a token belonging to the cached session.

3. Why You Were Never Prompted for Microsoft Credentials

Because the browser already had a valid Microsoft authentication session via:

• PingOne (if used)

• Native Windows sign-in

• Office apps auto-login

• VDI identity provider

Microsoft never prompts again unless that session is cleared.

4. How to Generate a Token for the Correct OneDrive Account

You must ensure the Microsoft session belongs to the OneDrive service account.

Correct procedure:

1. Sign out from all Microsoft apps (Teams, Outlook, OneDrive sync client)

2. Clear browser cookies

3. Open a clean incognito window

4. Manually sign in to Microsoft using the OneDrive service account

5. Log in to ServiceNow using the same account (real login, not impersonation)

6. Click Get OAuth Token

Now the token will belong to the correct OneDrive account.

5. Why Impersonation Does Not Work

Impersonation changes only the ServiceNow identity.

It does not (and cannot) change:

• The Microsoft identity

• Browser sessions

• SSO sessions

• Office login state

Thus, impersonation cannot control where files get stored.

6. Summary

ServiceNow does not decide where OneDrive files go.
The Microsoft account active during OAuth does.

To fix file uploads going to the wrong folder:

• Ensure the correct Microsoft identity is active

• Use clean browser isolation

• Log in to ServiceNow with the OneDrive service account before generating the token

Once properly configured, all files will upload into the correct OneDrive or SharePoint folder.

Read More

Understanding ServiceNow + OneDrive Integration: Why Two Microsoft Accounts Are Required

Understanding Why ServiceNow Needs Two Microsoft Accounts for OneDrive Integration

Integrating ServiceNow with Microsoft OneDrive often confuses teams—especially when they realize two different Microsoft accounts are involved:

1. A Microsoft OneDrive account

2. A Microsoft Azure AD (Entra ID) account

Why are both required? Let’s break it down clearly.

1. OneDrive Account — The Storage Identity

The OneDrive account is the identity that actually owns the files.

This is the account whose folder you will ultimately see files uploaded into. When ServiceNow pushes a document to OneDrive, it goes to the personal or shared folder of the account whose OAuth token ServiceNow is holding.

This account represents where the documents live.

2. Azure AD Account — The Admin Identity for App Registration

The Azure AD administrative account is used only for configuring the integration.

This account:

• Creates the App Registration

• Generates the Client ID

• Creates/rotates the Client Secret

• Grants Microsoft Graph API permissions

• Approves admin consent

This account does not store documents and does not represent a user on the OneDrive side.
It only provides the OAuth infrastructure.

3. Why You Cannot Use Only One Account

Because Microsoft separates:

• Identity used for API permissions (Azure)

• Identity owning the files (OneDrive)

ServiceNow must interact with both:

Function	Requires	Why
OAuth authentication	Azure account	App Registration + permissions
File upload	OneDrive account	Determines where the file is stored

4. Most Common Confusion in Organizations

Many teams mistakenly think:

“We updated the client secret in ServiceNow, but OneDrive still uploads into the wrong user’s folder.”

This happens because:

• The Azure credentials control the application

• The Microsoft session of whoever clicks “Get OAuth Token” controls the OneDrive identity

5. Summary

To successfully integrate:

• Use the Azure AD admin account only for configuring the OAuth application.

• Use the OneDrive service account to generate the OAuth token that ServiceNow will use during runtime.

Both identities serve different purposes, and both are required for a functional and secure integration.

Read More