Introduction

ServiceNow SharePoint integration connects ServiceNow workflows and records with Microsoft SharePoint Online so that organizations can automate document management, collaboration, file access, and business processes across the two platforms. In a typical enterprise implementation, ServiceNow manages requests, incidents, cases, approvals, policies, and workflows, while SharePoint stores documents, folders, collaboration content, and Microsoft 365 files.

This integration becomes particularly useful when a business does not want employees or agents to manually download documents from SharePoint and attach them to ServiceNow records. Instead, ServiceNow can create folders, copy attachments, retrieve files, manage SharePoint content, or use SharePoint as an external content source.

ServiceNow provides a Microsoft SharePoint Online Spoke through IntegrationHub. The current ServiceNow documentation identifies version 2.11.3 as the latest spoke version and describes predefined actions that can be incorporated into workflows.

From an implementation perspective, the important point is that this is not simply a “file upload” integration. Authentication, Microsoft Entra ID application permissions, SharePoint site structure, API access, ServiceNow connections, error handling, and security must all be designed together.

What Is ServiceNow SharePoint Integration?

ServiceNow SharePoint integration allows ServiceNow to communicate with Microsoft SharePoint Online using supported integration mechanisms, including the Microsoft SharePoint Online Spoke and Microsoft Graph-based connectivity.

At a high level:

ServiceNow
   |
   | IntegrationHub
   |
   | OAuth Authentication
   |
Microsoft Graph / SharePoint APIs
   |
   v
Microsoft SharePoint Online
   |
   +-- Sites
   +-- Document Libraries
   +-- Folders
   +-- Files
   +-- Lists
   +-- List Items

Microsoft Graph exposes SharePoint resources such as sites, lists, list items, and document libraries (drives), with read/write capabilities for supported resources.

For example, a company may have:

• ServiceNow HR Case Management
• SharePoint HR Documents site
• Employee case folders
• Policy documents
• Investigation documents
• Approval documents

Instead of asking an HR agent to manually locate and upload documents, ServiceNow can automate the interaction with SharePoint.

ServiceNow SharePoint Integration Architecture

A practical architecture normally contains four major layers.

The flow can look like this:

ServiceNow Case
      |
      v
Flow Designer
      |
      v
IntegrationHub Action
      |
      v
OAuth Connection
      |
      v
Microsoft Graph
      |
      v
SharePoint Site
      |
      +---- Document Library
      |
      +---- Folder
      |
      +---- File

Microsoft Graph represents a SharePoint document library as a drive. A site’s default document library can be accessed through /sites/{siteId}/drive, while additional document libraries can be enumerated through /sites/{siteId}/drives.

This distinction is important during implementation because a SharePoint URL visible to an end user is not necessarily the identifier that your integration should use for every operation.

Real-World ServiceNow SharePoint Integration Use Cases

Use Case 1 – HR Case Documents

Consider an organization with 50,000 employees.

An employee submits an HR case in ServiceNow and supporting documents need to be stored in SharePoint.

The process can be:

1. Employee creates an HR case.
2. ServiceNow generates a case number.
3. Flow Designer starts an integration.
4. A SharePoint folder is created.
5. Supporting documents are copied to the folder.
6. ServiceNow stores the SharePoint location.
7. HR agents access the documents through the case.

Example:

HR Case: HRC0008452

SharePoint:
HR Cases/
   HRC0008452/
      Employee_Document.pdf
      Manager_Statement.docx
      Investigation_Notes.docx

This provides a consistent document structure instead of allowing agents to create folders manually.

Use Case 2 – IT Request Attachments

Suppose an IT procurement request requires:

• Vendor quotation
• Purchase proposal
• Security assessment
• Approval document

The requester submits the request in ServiceNow.

When the request reaches the “Approved” state, ServiceNow can create or update a SharePoint folder and transfer required documents.

This is useful when SharePoint is the organization’s controlled document repository while ServiceNow remains the workflow system.

Use Case 3 – Policy Approval

A governance team maintains policies in SharePoint.

ServiceNow manages:

• Policy review
• Approval
• Assignment
• Due dates
• Compliance tracking

SharePoint maintains the actual documents.

A workflow could be:

Policy Record
     |
     v
Review Required
     |
     v
SharePoint Document
     |
     v
Reviewer
     |
     v
Approval
     |
     v
ServiceNow Policy Record Updated

ServiceNow documentation also describes scenarios where policy documents can be linked to ServiceNow policy records, collaborated on in cloud storage, and eventually published into ServiceNow knowledge content.

Key Integration Capabilities

The exact actions available depend on the installed spoke version and ServiceNow application scope, but common implementation requirements include operations around:

• Sites
• Document libraries
• Folders
• Files
• Attachments
• Users
• Groups
• Permissions
• Lists
• List items

Microsoft Graph itself supports read/write operations for supported SharePoint lists, list items, and drive items.

For example, Microsoft Graph provides APIs for retrieving SharePoint file content through drive item endpoints such as:

GET /sites/{siteId}/drive/items/{itemId}/content

Prerequisites

Before building the integration, establish the following.

ServiceNow prerequisites

You typically need:

• ServiceNow instance
• IntegrationHub subscription
• Microsoft SharePoint Online Spoke
• Appropriate ServiceNow roles
• Flow Designer access
• Connection and credential configuration

ServiceNow explicitly identifies an IntegrationHub subscription as a prerequisite for the Microsoft SharePoint Online Spoke.

Microsoft prerequisites

The Microsoft side generally requires:

• Microsoft 365 tenant
• SharePoint Online
• Microsoft Entra ID access
• App registration
• Client/application ID
• Tenant ID
• Appropriate API permissions
• SharePoint site access
• Administrator consent where required

ServiceNow’s current Graph connection documentation identifies access to the Azure portal and creation of an OAuth application as prerequisites.

Step-by-Step ServiceNow SharePoint Integration Setup

Step 1 – Install or activate the SharePoint Online Spoke

In ServiceNow, identify the Microsoft SharePoint Online Spoke available through IntegrationHub.

The spoke is designed specifically to allow ServiceNow workflows to invoke predefined SharePoint actions.

After installation, validate that the required integration components are active.

Do not immediately start building flows.

First confirm:

• Spoke is installed
• IntegrationHub is available
• Required roles are assigned
• Connection functionality is available

Step 2 – Create the Microsoft Entra ID Application

Sign in to the Microsoft Azure portal and navigate to:

Microsoft Entra ID → App registrations → New registration

Create an application specifically for the ServiceNow integration.

Example:

Record the:

• Application/client ID
• Directory/tenant ID

Do not put secrets directly into ServiceNow Flow Designer steps.

They should be handled through the supported credential and connection framework.

Step 3 – Configure API Permissions

The integration application needs permissions appropriate to the operations it will perform.

For example, if the application only needs to read SharePoint documents, do not automatically grant broad write permissions.

Microsoft’s documentation shows that SharePoint and drive APIs support different permission levels, with lower-privilege permissions available depending on the operation.

A consultant should create a permission matrix before requesting access.

Example:

The actual Microsoft permission should be validated against the exact Graph endpoint and authentication model being implemented.

Step 4 – Grant Administrator Consent

After permissions are configured, an authorized Microsoft administrator may need to provide tenant-wide consent.

This is a common implementation checkpoint.

If consent has not been granted, ServiceNow may successfully authenticate against Microsoft but fail when attempting to access SharePoint resources.

A common error pattern is:

Authentication successful
        |
        v
API request
        |
        v
403 Forbidden

This usually indicates an authorization problem rather than a ServiceNow connectivity problem.

Step 5 – Configure the ServiceNow Graph Connection

ServiceNow’s current documentation provides a specific procedure for configuring the Microsoft SharePoint Graph connection.

A typical configuration involves:

ServiceNow → Connections & Credentials

Configure the appropriate connection and credential records for SharePoint/Graph.

Depending on the implementation, maintain separate records for:

• Development
• Test
• Production

Do not reuse production credentials in development.

Step 6 – Validate the Connection

Before creating a business flow, test authentication independently.

The objective is to answer:

Can ServiceNow authenticate and access the intended SharePoint tenant?

Only after this succeeds should you troubleshoot the actual business flow.

ServiceNow documentation also describes retrieving an OAuth token after creating the credential and connection configuration.

Step 7 – Identify the SharePoint Site

Suppose your SharePoint URL is:

https://contoso.sharepoint.com/sites/HR

Microsoft Graph supports locating a SharePoint site by path.

The implementation should determine:

• SharePoint hostname
• Site path
• Site ID
• Document library/drive ID
• Folder structure
• File identifier

Do not hard-code a complete SharePoint URL into every flow step if the underlying API expects a site or drive identifier.

A better pattern is to maintain environment-specific configuration.

Step 8 – Identify the Document Library

A SharePoint site can contain multiple document libraries.

For example:

HR Site
 |
 +-- Documents
 |
 +-- Employee Cases
 |
 +-- Policies
 |
 +-- Templates

Microsoft Graph provides the ability to list drives associated with a SharePoint site.

For an HR case integration, you might select:

Employee Cases

as the target library.

Step 9 – Build the Flow in ServiceNow

Navigate to:

All → Flow Designer → New → Flow

Example trigger:

When HR Case is created

Then add actions such as:

Trigger
   ↓
Validate Case
   ↓
Create SharePoint Folder
   ↓
Copy/Upload Document
   ↓
Update ServiceNow Record

Example folder name:

HRC0008452

Example document path:

Employee Cases/HRC0008452/

The important design principle is to make the ServiceNow case number the correlation identifier.

Step 10 – Store the External Reference

After creating a SharePoint folder or file, store the relevant identifier in ServiceNow.

For example:

This becomes extremely useful for future operations.

Instead of searching SharePoint every time, the flow can use the stored external identifier.

Technical Integration Flow

A production integration can look like this:

ServiceNow Record
      |
      v
Flow Designer
      |
      v
IntegrationHub
      |
      v
SharePoint Online Spoke
      |
      v
OAuth / Microsoft Entra ID
      |
      v
Microsoft Graph
      |
      v
SharePoint Site
      |
      v
Document Library
      |
      v
Folder / File

For custom requirements, Microsoft Graph can expose SharePoint sites, lists, list items, drives, and drive items.

This means that when the out-of-box spoke action does not cover a specific requirement, a custom REST-based integration may be considered.

However, custom API development should not be the first option. First verify whether the current SharePoint Online Spoke already supports the requirement.

Testing the Integration

Testing should be performed in stages.

Test 1 – Authentication

Expected result:

OAuth authentication successful

If authentication fails, stop here and fix the connection.

Test 2 – Site Access

Use the configured connection to access the target SharePoint site.

Expected result:

Site found
Site ID returned

Test 3 – Document Library Access

Retrieve the configured document library.

Expected result:

Employee Cases
Drive ID: <ID>

Test 4 – Folder Creation

Create:

Employee Cases/HRC0008452

Expected result:

Folder created successfully
Folder ID returned

Test 5 – File Operation

Upload or copy:

Employee_Proof.pdf

Expected result:

File created successfully

Validate the file directly from SharePoint.

Test 6 – End-to-End Transaction

Create a real test case:

Case: HRC0008452
Attachment: Employee_Proof.pdf
Status: Submitted

Then verify:

1. Flow triggered.
2. Authentication succeeded.
3. SharePoint folder was created.
4. File was transferred.
5. External ID was returned.
6. ServiceNow record was updated.
7. User can access the document.
8. No duplicate folder was created.

Common ServiceNow SharePoint Integration Errors

1. 401 Unauthorized

Usually indicates an authentication problem.

Check:

• Client ID
• Client secret/certificate
• Tenant ID
• OAuth configuration
• Token generation

2. 403 Forbidden

Authentication may be successful but the application does not have sufficient authorization.

Check:

• Microsoft Graph permissions
• SharePoint access
• Admin consent
• Site-level permissions

Do not solve a 403 simply by granting every available permission.

3. 404 Not Found

Common causes include:

• Incorrect site path
• Incorrect site ID
• Incorrect drive ID
• Deleted folder
• Wrong environment

Remember that SharePoint URLs, site IDs, drive IDs, and item IDs are different concepts.

4. Duplicate Documents

Suppose a ServiceNow flow retries after a timeout.

The first attempt may actually have created the SharePoint file even though ServiceNow did not receive the response.

The retry then creates another copy.

Use an idempotency strategy.

For example:

ServiceNow Case Number
+
Document Type
+
Document Version

can form a business key.

5. File Size Problems

Large attachments require special consideration.

Do not assume that a small test PDF represents production behavior.

Test:

• Small files
• Medium files
• Large files
• Multiple attachments
• Unsupported file types

6. Wrong SharePoint Library

Many enterprises have several document libraries with similar names.

For example:

Documents
HR Documents
HR Case Documents
Employee Documents

Do not rely only on display names.

Capture and validate the correct drive/library identifier.

Real Implementation Challenges

Challenge 1 – Security Ownership

A ServiceNow developer may create the integration, while the Microsoft administrator controls SharePoint permissions.

This creates a common ownership gap.

Create a responsibility matrix:

Challenge 2 – Environment Migration

Development may use:

dev.sharepoint.com

while production uses:

prod.sharepoint.com

Avoid hard-coding environment-specific values inside flows.

Use appropriate configuration records and credentials.

Challenge 3 – Document Security

A ServiceNow user being authorized to view a case does not automatically mean they should have unrestricted access to the SharePoint library.

This needs explicit security design.

Ask:

• Who owns the SharePoint document?
• Who can access it?
• Should the ServiceNow user receive a direct link?
• Should access be inherited?
• Should files be copied or merely linked?

Best Practices

1. Use Least Privilege

Grant only the Microsoft permissions required for the integration.

Microsoft documentation explicitly distinguishes lower-privilege and higher-privilege permissions for SharePoint/Graph operations.

2. Use Correlation IDs

Always maintain a reliable relationship:

ServiceNow Record
        ↕
SharePoint Folder/File

A case number or request number is usually a good business correlation key.

3. Design for Retry

External APIs can timeout.

Use:

• Retry logic
• Error handling
• Duplicate detection
• Transaction logging
• Status fields

4. Do Not Store Secrets in Scripts

Use ServiceNow’s supported connection and credential mechanisms.

Avoid:

var clientSecret = "MySecret123";

inside scripts.

5. Separate Authentication From Business Logic

The flow should conceptually be:

Authentication
      ↓
Connection
      ↓
SharePoint Action
      ↓
Business Processing

Do not mix credential management into every business flow.

6. Log Meaningful Information

Good logging:

Case: HRC0008452
SharePoint Site: HR
Operation: Create Folder
Result: Success
External ID: <folder-id>

Avoid logging:

• Client secrets
• Access tokens
• Sensitive employee information
• Confidential document contents

7. Prefer Out-of-Box Actions Where Possible

If the SharePoint Online Spoke already provides the required operation, use it instead of immediately creating a custom REST integration.

This generally reduces:

• Custom code
• Maintenance
• Upgrade risk
• Authentication complexity

ServiceNow maintains the SharePoint Online Spoke as an IntegrationHub component specifically for workflow automation.

SharePoint Search Integration Considerations

SharePoint can also be used as an external content source for ServiceNow search scenarios.

ServiceNow documentation describes a SharePoint Online Search Connector for crawling eligible SharePoint sites, subsites, drives, and related content.

However, consultants should distinguish between:

Transactional integration

Create Folder
Upload File
Update File

and

Search/content integration

SharePoint
    ↓
Indexing
    ↓
ServiceNow Search
    ↓
User searches content

These are different architectural requirements and should not be combined into one generic “SharePoint integration” design.

Also check the current ServiceNow release documentation before implementing the Search Connector because ServiceNow documentation notes release-specific lifecycle considerations for that connector.

When to Use Microsoft Graph Directly

Use Microsoft Graph when:

• The required operation is not available through the spoke.
• A specific SharePoint resource must be accessed.
• Advanced filtering is required.
• Custom API behavior is required.
• The integration architecture already standardizes on Microsoft Graph.

Microsoft recommends Microsoft Graph as the REST API approach for SharePoint Online integrations, and Graph exposes SharePoint sites, lists, drives, and related resources.

For example:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives

can retrieve document libraries associated with a site.

The important consultant rule is:

Use the simplest supported integration mechanism that satisfies the business requirement.

ServiceNow SharePoint Integration vs Manual Document Handling

The value is not simply saving a few clicks. The larger benefit is establishing a controlled relationship between the ServiceNow business transaction and the SharePoint document repository.

Frequently Asked Questions

1. Can ServiceNow integrate with SharePoint Online?

Yes. ServiceNow provides a Microsoft SharePoint Online Spoke through IntegrationHub for automating supported SharePoint operations from ServiceNow workflows.

2. Does ServiceNow SharePoint integration require Microsoft Graph?

Not every implementation needs to call Microsoft Graph directly. The ServiceNow SharePoint Online Spoke provides supported actions, while Microsoft Graph can be used when a custom or more specific API operation is required. Microsoft documents Graph as an API surface for SharePoint Online resources.

3. Can SharePoint documents be accessed from ServiceNow?

Yes, depending on the implemented integration and application capability. SharePoint documents can be integrated with ServiceNow workflows and document-related functionality, while specific implementations must account for authentication, permissions, site structure, and document access controls. ServiceNow also documents SharePoint-based document scenarios in its policy authoring capabilities.

Summary

ServiceNow SharePoint integration is most useful when ServiceNow controls the business process while SharePoint remains the organization’s document and collaboration platform.

A robust implementation normally consists of:

ServiceNow
   ↓
Flow Designer
   ↓
IntegrationHub
   ↓
SharePoint Online Spoke
   ↓
OAuth / Microsoft Entra ID
   ↓
Microsoft Graph / SharePoint
   ↓
Sites / Libraries / Folders / Files

The technically difficult part is rarely creating the first successful API call. The real implementation work is designing security, permissions, identifiers, retries, duplicate handling, environment migration, document ownership, and auditability.

For Oracle Cloud environments where ServiceNow and Oracle Fusion Cloud Applications coexist, the same architectural principles become particularly relevant when ServiceNow acts as the workflow layer, SharePoint acts as the collaboration/document layer, and Oracle Fusion or Oracle Integration Cloud participates as the enterprise application/integration layer. The Oracle Fusion Cloud Applications 26A documentation provides the current reference point for Oracle-side APIs and implementation capabilities.

For additional Oracle Cloud reference material, refer to Oracle Cloud SaaS Documentation and the applicable Oracle Fusion Cloud Applications 26A documentation. For SharePoint-specific implementation, also refer to the current ServiceNow Microsoft SharePoint Online Spoke documentation and Microsoft Graph SharePoint documentation