Salesforce SharePoint Integration (plus Box, Dropbox and Google Drive)

Your options at a glance

There are five realistic ways to keep Salesforce documents in SharePoint, Box, Dropbox or Google Drive. They solve different problems, so many teams combine two: Files Connect for browsing, plus automation for folders.

Two notes. First, Dropbox for Salesforce is not on the list because Dropbox ended support for it on October 14, 2025 (more below). Second, third-party SharePoint document apps on AppExchange (now AgentExchange) fill the folder-per-record gap too; test them in a sandbox and check where they store files and tokens. For how document storage fits into your wider architecture, see our Salesforce integration guide.

Why keep files outside Salesforce

Three reasons come up in almost every project: storage cost, one document system for the whole company, and tools that Salesforce Files doesn’t replace.

• Storage is small and expensive. According to Salesforce’s Data and File Storage Allocations page, Contact Manager, Group, Professional, Enterprise, Performance and Unlimited editions get 10 GB of file storage per org, and Essentials and Starter get 1 GB. Your contract may add per-license storage; check Storage Usage in Setup for your real number. Extra storage is bought from Salesforce.
• SharePoint is sized for documents. Microsoft lists 1 TB plus 10 GB per license of SharePoint storage for most Microsoft 365 business and enterprise plans, files up to 250 GB, and up to 30 million files and folders per library (Microsoft’s SharePoint limits page, October 2026).
• One place for documents. Contracts, proposals and case evidence often need co-authoring in Word or Excel, retention policies, eDiscovery and sensitivity labels. Those already live in Microsoft 365 or Google Workspace, so a second document store in Salesforce splits the truth.

The trade-off: files outside Salesforce are invisible to Salesforce reports, sharing rules and some mobile and portal features unless you build the bridge. That bridge is what this guide is about.

What Files Connect really does

Files Connect is the native feature, and most teams should start with it. It is also the most misunderstood one, so here is what it does and doesn’t do, based on Salesforce’s Files Connect implementation guide.

• Sources: SharePoint Online, OneDrive for Business, Google Drive and Box (Quip is set up separately). Each needs an authentication provider and an external data source in Setup.
• Editions: Professional, Enterprise, Performance, Unlimited and Developer.
• Copy or Reference: an org-wide choice. Copy stores a copy of the external file in Salesforce, and if it’s shared with a Chatter group, all members can open it even without access to SharePoint. Reference points to the external file: downloads need access in the external system, and the link always opens the latest version.
• Authentication: Per User (each user signs in to SharePoint, Google or Box, so their own permissions apply) or Named Principal (one shared account for everyone, available for SharePoint and Google Drive).
• Search: optional. You create an external object from the data source so external files show up in global search, SOQL and SOSL, and SharePoint custom properties can be included.
• What it doesn’t do: it doesn’t create a SharePoint folder for each account or opportunity, and it doesn’t move files that users upload to a record. Those stay in Salesforce storage.

Which option fits you?

How a folder-per-record integration works

This is the pattern most teams end up with for SharePoint: Salesforce creates the record, an integration creates the folder, and the folder link lives on the record.

How to set up Files Connect for SharePoint, step by step

You need a Salesforce admin with Customize Application and Manage Auth. Providers, and a Microsoft 365 admin who can register an app in Microsoft Entra ID (formerly Azure Active Directory). Do it in a sandbox first.

1. Choose Copy or ReferenceDecide before you enable anything. Reference keeps files in SharePoint and respects SharePoint permissions; Copy stores files in Salesforce. For storage savings and one source of truth, pick Reference.
2. Enable Files ConnectIn Setup, search for Files Connect, click Edit, select Enable Files Connect and set File Sharing to Copy or Reference.
3. Grant the permissionCreate a permission set with the Files Connect Cloud system permission and assign it to pilot users and to the admins who will configure data sources.
4. Create the authentication providerIn Setup, open Auth. Providers, create an OpenID Connect provider with placeholder key, secret and endpoint values, save it, and copy the Callback URL.
5. Register the app in Microsoft Entra IDIn the Azure portal, create an app registration for your own directory only, add a client secret, add the Salesforce callback URL as a Web redirect URI, and add SharePoint API permissions. Then replace the placeholders in the Salesforce auth provider with the real application ID, secret and endpoints.
6. Define the external data sourceIn External Data Sources, create a new one of type Files Connect: Microsoft SharePoint Online (or OneDrive for Business). Enter the site URL, not a page URL, choose Per User or Named Principal, OAuth 2.0 and your auth provider.
7. Let users sign inFor Per User, add the data source to the permission set’s External Data Source Access. Users then authenticate under Authentication Settings for External Systems in their personal settings.
8. Add search (optional, recommended)Validate and Sync the data source, create the external object from the items table, deploy it, grant read access to its fields, and add a tab in Lightning. Now SharePoint files show up in global search.
9. Pilot and check accessHave three users with different SharePoint rights try the same files. Confirm that people who can’t open a file in SharePoint can’t open it from Salesforce either.

Google Drive and Box follow the same shape: an OAuth client in Google Cloud (with the Google Drive API enabled) or in the Box developer console, an auth provider in Salesforce, then an external data source.

How to automate a folder per record

This is the part Files Connect leaves out. The steps are the same whether you use Power Automate, an iPaaS tool or custom code.

1. Pick the anchor objectUsually Account, with Opportunity and Case folders underneath. One library per object type keeps permissions and views simple.
2. Fix the naming ruleUse the record name plus the Salesforce record ID, for example “Acme Corp (001…)”. Names change and repeat; IDs don’t. Keep paths short: SharePoint allows 400 characters for the full decoded path.
3. Add fields to the recordA folder ID field and a folder URL field. Store the ID for the integration and the URL for people.
4. Trigger on creationA record-triggered flow calling Apex or an External Services action, a Power Automate “When a record is created” trigger, or an iPaaS recipe. Add entry criteria so test records and junk leads don’t get folders.
5. Create the folder through Microsoft GraphCreate it in the right library and parent folder, then write the folder ID and URL back to Salesforce in the same run.
6. Show it on the recordA URL field is enough to start. Later, a Lightning component that lists and uploads files to the folder saves users a click.
7. Handle the edge casesRenames (rename the folder or leave it, but decide), record merges (move the loser’s files), ownership changes, deletes, and records created by bulk imports.
8. MonitorLog every failure with the record ID and retry. A record without a folder is the first ticket you will get.

Microsoft Graph accepts files up to 250 MB in a single upload call; bigger files need an upload session, which matters if users upload from the Salesforce record page through your integration.

Mapping: which object gets which folder

Agree on this table with sales, service and legal before anyone builds. Salesforce owns the records; the document system owns the files.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

The permissions mismatch

This is where document integrations get into trouble with security. Salesforce decides record access through profiles, roles and sharing rules. SharePoint decides file access through site, library and folder permissions. Nothing keeps the two in sync unless you build it.

• Reference mode respects SharePoint. Users must have access in SharePoint to download the file. That is safe, but sales reps will complain when the account owner changes and the new owner can’t open the contract.
• Copy mode bypasses SharePoint. A copied file shared with a Chatter group is open to all group members, even without SharePoint access.
• Named Principal hides who is who. With one shared account, every Salesforce user with the data source can reach whatever that account can reach in SharePoint. Use it only for libraries that everyone may see.
• Per-folder permissions don’t scale. Microsoft supports up to 50,000 unique permissions in a list or library and recommends staying under 5,000. Once a library or folder holds more than 100,000 items, you can’t break or restore inheritance on it. A unique permission on every account folder hits those limits fast.
• App permissions are too broad by default. A custom integration with Sites.ReadWrite.All can write to every site in the tenant. Microsoft’s Sites.Selected and other Selected scopes limit an app to specific sites, lists or files.

The fix: design access at the library or site level, by team or region, not per record. If Salesforce access must decide document access (for example, for portal users or strict account teams), put the integration in the middle: users open files through Salesforce, and the integration checks record access before it serves the file.

Box, Dropbox and Google Drive specifics

Moving existing files out of Salesforce

Integration only helps new files. The storage bill is usually driven by years of old attachments, so migration is its own small project.

1. MeasureOpen Storage Usage in Setup and list the largest file owners and objects. Salesforce calculates storage asynchronously, so numbers lag after big changes.
2. Inventory both file typesSalesforce Files (ContentDocument and ContentVersion, linked to records through ContentDocumentLink) and legacy Attachments. Older orgs have both.
3. Decide what movesClosed deals older than a set age, case evidence, large media. Leave small, active files alone unless you want everything in one place.
4. Copy with the record contextDownload each file through the API, upload it to the record’s folder, keep the original name, author and dates in SharePoint columns, and store the Salesforce IDs for traceability.
5. Verify, then deleteCompare counts and checksums, have users spot-check, and only then delete the Salesforce copies (they go to the recycle bin first). Keep a link on the record so nothing feels lost.
6. Stop the inflowRoute new uploads to SharePoint through your folder integration, or the storage fills up again.

Pitfalls and fixes

When a custom integration makes sense

Files Connect and a few Power Automate flows cover most small and mid-size teams. A custom integration on Microsoft Graph (or the Box, Dropbox or Google Drive APIs) earns its cost when:

• Salesforce record access must decide who opens a document, for internal teams or portal users.
• You need upload, preview and version history on the record page, with files stored straight in SharePoint.
• You are migrating hundreds of gigabytes of existing files with metadata and an audit trail.
• Several Salesforce orgs, or Salesforce plus another CRM such as Dynamics 365, share one document structure. See our Salesforce Dynamics 365 integration guide for that case.
• Volume is high enough that per-task iPaaS pricing or polling becomes the bottleneck, or you already run an integration layer such as MuleSoft.

A typical build includes an Entra ID app with Selected scopes, a named credential in Salesforce, folder creation and write-back, a Lightning component for files, a migration job, logging and retries. In line with our API integration cost guide:

For the wider picture of data projects, see the cost of data integration.

Go-live checklist

Tick what is already true. It shows how ready your document integration is.

FAQ

Where Gilzor fits

Gilzor builds and maintains Salesforce integrations from Poland and Cyprus (see Salesforce integration services). Gilzor’s engineers can map which records need folders and who should see them, build the SharePoint, Box or Google Drive integration and the file migration, and support it after launch. More Salesforce connections are covered in the Salesforce integration guide.