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.