Ultimate Troubleshooting Guide: Fixing ServiceNow + OneDrive OAuth, Token, and 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 guide gives precise workflows to identify and resolve root causes related to ServiceNow OneDrive integration, and ties together the full troubleshooting path covered across this blog's OneDrive series — including where to stop troubleshooting a symptom and instead fix the underlying architecture.

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 the Azure App Registration.
• Its Client Secret is valid.
• Grant Type is set appropriately for your setup — commonly Authorization Code for a delegated-permissions OneDrive Spoke configuration.

If there are duplicate profiles, delete or deactivate the unused ones — a stray second profile pointing at the same Azure app registration is a common, avoidable source of "which token actually got used" confusion.

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 the OneDrive sync client logged in?

Incorrect account means incorrect OAuth token — this single check resolves more of these tickets than anything else on this list, which is why it comes early rather than last.

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

To issue the correct token:

1. Sign out from all Microsoft apps.
2. Clear browser cookies and 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 — this Windows-level SSO broker is what silently re-signs the browser into a cached Microsoft account even after cookies are cleared, and it's a step that's easy to miss since it isn't a browser setting at all.

5. Test OneDrive Spoke Connectivity

Test using:

OneDrive → List Drive Items

• If results come from the wrong drive, the token is wrong.
• If unauthorized, permissions are wrong.
• If empty, the token is correct but the folder path is wrong.

6. Validate Graph Permissions

Your Azure App Registration must include, for a delegated setup:

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 — one of the more misleading failure modes here, since the token generation step itself won't show any error at all.

7. Confirm the OneDrive Service Account Actually Has OneDrive Enabled

Go to the Microsoft Admin Center and confirm:

• The account has a valid OneDrive license.
• It has logged in to OneDrive at least once.
• Storage is provisioned.

If not, the OneDrive Spoke will fail with misleading errors that look like an authentication problem rather than a licensing one.

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

Find the token owner:

sys_oauth_credential.list

Look at the field recording who authorized the token. If this shows an admin account or any user other than your intended service account, the wrong identity issued the token — exact field labels can shift slightly by release, so confirm against your instance if the name doesn't match exactly.

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 the Token If Needed

If things are completely broken:

1. Remove OAuth tokens from sys_oauth_credential.
2. Remove the token from the OneDrive Spoke credential.
3. Restart the token flow, following Step 4 above.

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

If You're Troubleshooting This Repeatedly, Consider the Structural Fix

Everything above resolves the delegated-permissions failure modes this series has covered — and it works. But it's worth stepping back and asking whether repeated trips through this checklist are actually the right long-term state for an integration your organization depends on.

The root cause underlying most of these ten steps is the same one covered across this blog's OneDrive series: a delegated OAuth flow ties the upload destination to whichever Microsoft session happened to be active when a token was generated, and that's inherently fragile in SSO-heavy, VDI-based enterprise environments. ServiceNow's Microsoft SharePoint Online Spoke supports an alternative — a certificate-based application identity, authenticated via its own Connection & Credential Alias, with the option to scope access down using Sites.Selected rather than organization-wide permissions. Because there's no signed-in user involved, there's no session to mismatch in the first place — steps 3, 4, and 8 above stop being relevant at all.

A couple of practical notes if you make this switch:

• Connection & Credential Alias records aren't captured in Update Sets, so each environment needs its own configuration rather than one promoted through the normal change pipeline — budget for that during a migration rather than discovering it mid-cutover.
• This is a genuine architecture change, not a settings toggle — plan it as a project with proper testing, not a quick Friday-afternoon fix.

If your team is running this troubleshooting guide more than once every so often, that recurrence is itself the signal worth acting on.

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.

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

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 the mechanics first, then cover the two ways to actually get past this permanently rather than managing around it every time.

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.

ServiceNow is simply the redirect channel here. Microsoft chooses the identity, based entirely on whatever browser session happens to be active at that moment.

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, and the 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 — none of the ServiceNow-side workarounds above touch Microsoft's own session state.

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, or a VDI identity provider. Microsoft never prompts again unless that session is explicitly 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, or Office login state. Impersonation is entirely a ServiceNow-side concept; Microsoft's authentication layer has no awareness of it whatsoever. Thus, impersonation cannot control where files get stored.

6. The Newer Alternative: The Official Microsoft OneDrive / SharePoint Online Spoke

Everything above describes how to correctly manage the delegated OAuth flow — but it's worth being direct about what it actually is: a manual, session-dependent process that has to be redone carefully every time the wrong Microsoft identity gets cached. If this keeps happening on your instance, it's worth considering ServiceNow's official Microsoft OneDrive Spoke and Microsoft SharePoint Online Spoke, available through Integration Hub, as a structural fix rather than a repeated manual procedure.

Here's what makes this genuinely different, not just more convenient: the SharePoint Online Spoke's standard setup uses a certificate-based application identity — an Azure app registration authenticating with a certificate rather than a delegated user session — with the option to scope access down to Sites.Selected instead of the broader Sites.FullControl.All. This is the application-permissions model, the same structural fix discussed in this blog's companion article on why ServiceNow needs two Microsoft identities. Because there's no signed-in user involved, there's no "whichever session happens to be cached" problem to manage at all — the identity is fixed at the application level, not determined by whoever's browser session is active when a token gets requested.

A few practical setup notes if you go this route:

• The Spoke uses a Connection & Credential Alias to store its authentication configuration — worth knowing that these records are not captured in Update Sets, so each environment (Dev, Test, Prod) needs its connection, credential, alias, and app registration configured fresh rather than promoted through the normal change pipeline. Static values like the OAuth app registry details can be stored in a system property and referenced across environments to reduce repeated manual entry.
• If you hit authentication errors during setup specifically, check Key Management > Module Access Policies — this module isn't always available to admins by default, and a missing or misconfigured target script entry (commonly surfaced as an OAuthUtilSPJWTOnline-related script) is a known, specific cause of setup-time authentication failures.
• Choose Sites.Selected over Sites.FullControl.All during setup wherever your integration only needs to reach specific document libraries — this keeps the Spoke's broader application-level reach appropriately scoped rather than granting organization-wide access by default.

Summary

ServiceNow does not decide where OneDrive files go — the Microsoft account active during OAuth does, if you're using the delegated flow described in Sections 1 through 5. To fix file uploads going to the wrong folder under that model:

• 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, files will upload into the correct OneDrive or SharePoint folder — but if this is a recurring operational headache rather than a one-time setup issue, moving to the certificate-based Microsoft OneDrive or SharePoint Online Spoke removes the session-dependency at its root, rather than requiring the careful manual procedure above every time it resurfaces.

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

Integrating ServiceNow with Microsoft OneDrive often confuses teams — especially when they realize two different roles are involved, sometimes represented by two different Microsoft accounts:

1. The identity that ends up owning the uploaded files (the OneDrive/runtime identity)
2. The Entra ID administrative identity used to configure the integration itself

Why does this split exist, and — this is the part most explanations skip — is it actually unavoidable? Let's break it down, including the architecture that avoids the split entirely.

1. The Runtime Identity — Where Files Actually Land

This is the identity that actually owns the files ServiceNow uploads. When ServiceNow pushes a document to OneDrive, it goes to the personal or shared folder belonging to whichever identity's OAuth token ServiceNow is holding at the time.

This identity represents where the documents live — not who configured the integration.

2. The Entra ID Admin Identity — Configuring the Integration

The Entra ID (formerly Azure AD) administrative account is used only for configuring the integration. This account:

• Creates the App Registration
• Generates the Client ID
• Creates and rotates the Client Secret
• Grants Microsoft Graph API permissions
• Approves admin consent

This account does not store documents and doesn't represent a file-owning user on the OneDrive side — it only provides the OAuth infrastructure the integration runs on.

Worth being precise about: both of these are Microsoft Entra ID identities under the hood — there isn't a separate "OneDrive account" type distinct from an Entra ID account. The real distinction is about role in the OAuth flow: one identity does one-time administrative setup, and a separate identity's session (in one specific architecture, covered next) determines where files actually land at runtime.

3. Why This Split Exists — In the Delegated Permissions Model Specifically

This is the detail that changes everything about how to think about this problem: the two-identity split described above is a real, well-documented consequence of delegated permissions — one of two permission models Microsoft Graph API supports for OneDrive access — not an unavoidable fact about ServiceNow+OneDrive integration in general.

In the delegated model, the app calls Microsoft Graph on behalf of a signed-in user. Two identities genuinely participate: a real user who consents to delegate their access, and the application (via its Entra ID registration) that receives temporary delegated access to act within that user's permissions. The application's effective permissions are the intersection of what it's been granted and what that specific signed-in user is actually allowed to do — it can never exceed the user's own access.

Function	Requires	Why
OAuth application setup	Entra ID admin account	Creates the App Registration and grants permissions
File upload destination	Runtime user session	Delegated tokens act within that specific user's own OneDrive

4. The 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, under the delegated model:

• The Entra ID credentials control the application's identity and permissions.
• The Microsoft session of whoever last completed the OAuth consent ("Get OAuth Token") flow controls which OneDrive the files actually land in.

Rotating a client secret doesn't touch the second part at all — the upload destination is tied to whichever user's session generated the currently-held delegated token, and that can silently be a different person than whoever the team assumes "owns" the integration.

5. The Alternative: Application Permissions (No Second Identity Required)

This is the option worth strongly considering if the delegated model's session-dependent behavior has already caused confusion, or if a predictable, admin-controlled upload destination matters more than convenience of setup.

Microsoft Graph also supports application permissions (via the OAuth Client Credentials grant), where the app acts under its own identity — no signed-in user involved at all. With application permissions like Files.ReadWrite.All, the target user or site is specified explicitly in the API path (for example, /users/{userPrincipalName}/drive or /sites/{siteId}/drive), rather than being implicitly determined by whoever's session token happens to be active.

This directly eliminates the confusion described in Section 4: there's no "whoever clicked Get OAuth Token" ambiguity, because the destination isn't session-dependent at all — it's whatever your integration explicitly specifies, every time, consistently.

The tradeoff: application permissions are broader by nature — a permission like Files.ReadWrite.All at the application level can potentially reach any user's files in the organization, so admin consent and scope review matter more here, not less. Microsoft's own Sites.Selected permission (which now supports application mode) is worth knowing about specifically because it lets you restrict an application's access to specific sites/document libraries rather than granting organization-wide reach — a meaningfully safer middle ground for a ServiceNow integration that only needs to write to one specific document location.

6. Summary and Recommendation

If you're already using the delegated model:

• Use the Entra ID admin account only for configuring the OAuth application.
• Use a specific, intentionally-chosen runtime account to generate the OAuth token ServiceNow will hold — and treat "which account last authenticated" as a piece of configuration worth documenting explicitly, not something to leave implicit.

If predictable, admin-controlled file destination matters more than initial setup simplicity — which is true for most enterprise document-management use cases — application permissions, scoped down with Sites.Selected where possible, avoids the two-identity confusion entirely rather than just managing around it.

Both models are valid Microsoft Graph architectures. The choice isn't "which is correct" — it's which tradeoff fits your integration: delegated is simpler to reason about for a single user's personal files, while application permissions trade broader scope for eliminating the exact session-dependent ambiguity that causes the most common support confusion described above.