Salesforce SharePoint Integration Guide

A sales manager is reviewing a £500,000 opportunity in Salesforce. The customer's proposal is in SharePoint. The latest contract is in another folder, while a technical document sits in a Teams-linked library.

Finding the files is not necessarily the difficult part. The frustration comes from leaving Salesforce, searching SharePoint, checking which version is current, and then returning to the opportunity.

A Salesforce SharePoint integration brings these two sides of the workflow closer together. Salesforce continues to manage customer and sales information, while SharePoint remains the document repository for contracts, proposals, project files and other business records.

For organisations already using Microsoft 365, this can also reduce the need to store large document collections in Salesforce. Salesforce's native Files Connect provides a starting point for accessing SharePoint content, while requirements such as automated folders, metadata mapping, document routing and workflow triggers need a broader integration approach.

Why Should You Integrate Salesforce with SharePoint?

The reason is straightforward: the customer record and the documents that support it often stay in different places.

A large opportunity might contain the account details, contacts, deal value, stage, and activity history in Salesforce. The proposal, statement of work, pricing schedule, technical documents, and signed contract may stay in SharePoint.

Without a connection between the two, users switch systems to find the latest document.

With the right Salesforce integration, Salesforce provides the customer context while SharePoint continues to handle the documents. This is particularly useful when SharePoint is already the organisation's established document platform. There is little value in moving thousands of existing files simply to make them available from a CRM user interface.

Example: Salesforce Opportunities and SharePoint

A professional services company could have a SharePoint site for each major client.

When an opportunity reaches the proposal stage, the sales team may need access to:

• Proposal documents
• Pricing schedules
• Technical specifications
• Statements of work
• Legal documents
• Previous versions
• Customer correspondence

Instead of copying these files into Salesforce, the business can connect the opportunity to the relevant SharePoint content.

The Salesforce record remains the place to manage the opportunity. SharePoint remains responsible for storing and managing the documents.

How Does Salesforce SharePoint Integration Take Place?

There are three main approaches. The important distinction is whether users simply need access to documents or whether Salesforce and SharePoint need to exchange information and perform actions.

Option 1: Salesforce Files Connect

Files Connect is Salesforce's built-in way to connect external content sources such as SharePoint Online. It lets users access, search, and share external files through Salesforce.

This is a good option when the requirement is essentially:

Let Salesforce users find and work with relevant SharePoint documents without turning Salesforce into the document repository.

For SharePoint Online, Salesforce uses an external data source configuration with OAuth 2.0 authentication. Administrators define the SharePoint site URL, authentication provider, and identity type.

Option 2: API Integration

An API-based integration gives developers more control over what happens when Salesforce records change.

For example, it could:

1. Create a SharePoint folder when a new Salesforce Account is created.
2. Store the SharePoint folder reference against the Account.
3. Apply a standard folder structure based on the customer or record type.
4. Route documents to the correct location.
5. Write the SharePoint URL back to Salesforce.

This requires more development than Files Connect, but it becomes useful when document handling needs to follow specific business rules.

Option 3: Middleware

Middleware sits between Salesforce and SharePoint and manages the exchange of information.

Salesforce → Integration Layer → SharePoint

This approach is useful when Salesforce is already connected to several other systems. The same integration layer might handle Salesforce-to-ERP, Salesforce-to-finance, or Salesforce-to-portal workflows, with common error handling and monitoring.

The practical distinction is simple:

Files Connect is best for access. APIs for custom logic. Middleware when several systems and workflows need to work together.

Salesforce Files Connect and SharePoint Online

For a business that mainly wants users to access SharePoint content from Salesforce, Files Connect is the logical place to start.

Salesforce allows administrators to define Files Connect: Microsoft SharePoint Online as an external data source. The configuration includes the SharePoint site URL, OAuth 2.0 authentication, and the identity model used to access the source.

The site URL matters. Salesforce expects the SharePoint site, site collection, or web application URL rather than the URL of an individual SharePoint page.

Administrators also need to decide how users authenticate:

• Per User: each user authenticates with their own credentials.
• Named Principal: Salesforce uses a common identity for access to the external data source.

Files Connect can also be configured as part of a Salesforce implementation to handle external files as references or copies. A reference points users to the file in SharePoint and retains the external system's access controls. A copied file is stored in Salesforce and can then be shared through Salesforce.

The standard Files Connect experience is primarily designed for accessing external content rather than managing a complete document lifecycle inside Salesforce. Salesforce does provide API-based write capabilities for external documents, so more advanced document actions should be assessed separately.

What Can Salesforce and SharePoint Integration Automate?

This is where a basic connection ends and a more capable integration starts.

Record-Driven Folder Creation

When a Salesforce Account, Opportunity, or Case is created, an automation can create the corresponding SharePoint location.

For example:

Account → Opportunity → Commercial → Technical → Legal

That removes the need for staff to create the same folder structure manually.

Document Routing

Files can be directed to different SharePoint libraries or folders according to Salesforce fields.

A project marked as "UK" could go to one SharePoint location, while another region uses a different library.

Metadata Mapping

Salesforce fields such as Account Name, Opportunity ID, Project Type, or Region can be passed into SharePoint metadata where the integration supports it.

This makes SharePoint search and filtering more useful without requiring employees to enter the same information twice.

URL Write-Back

Once a SharePoint document or folder has been created, the integration can write the URL back to the relevant Salesforce record.

Users then have a direct route from the opportunity or case to the document location.

Notifications and Approvals

A Salesforce event could trigger a Power Automate workflow that sends a notification through Microsoft Teams or starts a document approval process.

These functions need automation, APIs, Flow, or an integration product rather than a basic external file connection.

Salesforce SharePoint Integration Example

Consider a UK construction company using Salesforce to manage commercial opportunities.

The opportunity record contains the customer, opportunity value, expected close date, sales stage, account manager, and project type.

The supporting documents stay in SharePoint, using a structure such as:

Customer → Project → Commercial → Technical → Legal

When the opportunity reaches the proposal stage, the sales team can access the relevant document location from Salesforce.

After the opportunity is won, the same SharePoint structure can continue supporting the delivery team.

The benefit is not simply fewer clicks. Sales and delivery are working from the same document structure instead of creating separate repositories as the customer moves through the business.

How to Set Up Salesforce SharePoint Integration

The exact process depends on the architecture, but a Files Connect implementation generally involves these stages.

Define the Business Requirement

Start with the workflow, not the technology.

Decide whether users need to:

View SharePoint files from Salesforce

• Search SharePoint content
• Create SharePoint folders automatically
• Upload documents
• Synchronise metadata
• Trigger workflows between the systems

These are different requirements. A simple external file connection should not be stretched to cover a process that really needs automation.

Review the SharePoint Structure

Before connecting anything, review the existing SharePoint environment.

Check:

• Sites
• Libraries
• Folders
• Metadata
• Permissions
• Naming conventions
• Document ownership
• Retention rules

If users already struggle to find documents in SharePoint, integrating Salesforce will not fix the underlying structure.

Configure Authentication

For SharePoint Online, Salesforce's Files Connect configuration uses OAuth 2.0. Administrators also choose between Per User and Named Principal authentication.

The choice matters because it affects how access is enforced and managed.

Define the External Data Source

In Salesforce Setup, create the external data source for SharePoint Online.

Enter the correct site URL, authentication provider, and identity type. Salesforce also provides an option to restrict the connection to the specified site collection.

Control User Access

Do not give every Salesforce user access to every SharePoint location.

A salesperson might need proposals and pricing documents but not internal legal files.

Salesforce permissions and SharePoint permissions should therefore be reviewed together. Salesforce also requires the relevant Files Connect Cloud permission and access to the configured external data source.

Where possible, follow least privilege: give users access only to the sites and libraries required for their role.

Test Different User Roles

A successful authentication test is not enough.

Test the integration with users who have different SharePoint permissions:

• Sales user
• Sales manager
• Legal user
• External or portal user, where applicable

Run real scenarios such as:

Account → SharePoint site → Customer folder → Contract

and:

Opportunity → Proposal folder → Document access

Then test what happens when the user does not have permission to the underlying SharePoint location.

Salesforce SharePoint Integration: Security and Permissions

Security needs to be designed across both platforms.

Salesforce and SharePoint have separate permission models. Connecting them does not make those models identical.

A user might have access to a Salesforce Account but not to the corresponding SharePoint library. The reverse can also happen.

That is why access testing should cover different roles rather than relying on the administrator account.

The authentication model matters too. With Per User, each user authenticates against the external source. With Named Principal, Salesforce uses a common identity for access to the data source.

For organisations handling contracts, financial records, employee documents or regulated information, this decision should be documented as part of the integration design.

Common Salesforce SharePoint Integration Challenges

Authentication Problems

A Files Connect connection can show as authenticated while a user still receives an error when opening a SharePoint folder.

Before changing the Salesforce configuration, check the Azure application permissions, SharePoint site URL, and the user's access to the underlying library.

Salesforce has also documented recent Files Connect issues where authentication appeared successful, but users could not access SharePoint content because of permission or configuration problems.

Incorrect SharePoint Site URLs

Use the SharePoint site, site collection, or web application URL expected by Salesforce. Do not paste the URL of an individual SharePoint page into the Site URL field.

Permission Mismatches

A Salesforce user might see the Account or Opportunity but receive an access error when opening the related SharePoint content.

Check both sides of the permission model before assuming the integration itself is broken.

Poor Document Structure

If different teams use different customer names, folder structures, or naming conventions, users will still struggle to find documents.

Fix the SharePoint structure before trying to automate it.

File Preview Limitations

Files Connect does not provide the same preview experience for every external file. Salesforce currently states that files from SharePoint Online or OneDrive for Business cannot be previewed in the Salesforce file preview player.

Test this if users expect documents to open entirely inside Salesforce.

Salesforce SharePoint Integration vs Moving Files into Salesforce

Integration does not necessarily mean moving documents.

If SharePoint is already the organisation's document-management platform, moving everything into Salesforce could create duplicate files, additional storage requirements, and another permission structure to maintain.

Keeping the documents in SharePoint while surfacing relevant content through Salesforce can be a better fit.

There are exceptions. If the business needs Salesforce-native file functionality or specific workflows around Salesforce Files, keeping selected documents in Salesforce may make sense.

The decision should be based on how the documents are actually used.

When Should You Use Files Connect, APIs or Middleware?

You can use this information as the practical decision point: