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.