# Salesforce document management with SharePoint: buyer's guide

> Whether what you already own covers your document workflow, and what to require of anything you add. Every claim dated and sourced.

*Buyer's guide*

## Salesforce document management with *SharePoint*

Is what you already own enough, and if it isn't, what should you require of whatever you add?

## The short answer
There is only one right path for you. Each costs something different.

 Native FilesFiles stay in Salesforce. Nothing to set up. Storage is capped per org.

 Files ConnectRead SharePoint from a record. Free, but it needs configuring and stays read-only.

 External AppFolders, automation, portal users. Buy it or build it.

## However
The route you **want** may not be the route you **need**. Telling them apart takes facts, not impressions. Ours are sourced, dated, and flagged where they’re only judgement. The one step left is yours: answer from what your workflow does today. Here’s what you can do next, depending on how much time you want to spend on it.

Quick2–3 daysFill in one short form. A person reads it and sends back a free, vetted analysis of where you actually are.

[Check my working →](#check)Quickera few minutesPick the questions that matter to you: storage, users, and what it takes to run a document suite inside Salesforce.

[The questions that decide it →](#questions)Quickest10 secondsAnswer three questions and get the single next action that fits you.

[What to do next →](#next-step)

## The questions that decide it
Nine questions, in three groups. Each is answered here, limitations included. Answer them about your own workflow, not the one you wish you had.

Group 1
### Where files live, and how they’re organised
Whether files leave Salesforce, what already reaches them if they do, and how they attach to a record.

#### Do these files need to live outside Salesforce at all?
Salesforce allocates file storage **per org, not per user**, so headcount tells you nothing. Plenty of teams check and find they have years of headroom. Setup → Storage Usage gives you the number before you argue about it.

#### Is Files Connect enough on its own?
It is included with the platform and genuinely sufficient for reading. It **cannot create or update a file in the Salesforce interface**. That path runs through the Chatter REST API, which is a build.

#### Do files attach to records one at a time, or as folders?
Linking one document is trivial. Keeping a folder **and everything inside it** in step with a record, as both change, is a different problem.

Group 2
### Who touches them
Three kinds of actor: your own users, people outside your org, and no one at all.

#### Which identity actually reaches your SharePoint?
Ours: internal users authenticate as themselves; automations and portal users run on a single **account-level identity**. Those are two different security stories, so ask any vendor which one you get, and for which operations.

#### Do people outside your org need access?
External users have no Microsoft identity of their own, so something brokers access for them, and **whatever does that becomes your security boundary**. Ask precisely how it works.

#### Does anything have to happen without a person?
Ask for a count you can check, then ask what happens when one fails. Ours: **48 Flow actions and 43 Apex methods**, publicly documented, counted 17 August 2026. Large uploads retry, **other operations do not**, and a failed multi-step run can leave a partial state.

Group 3
### What it takes to run
What you carry in, what happens as it grows, and what the whole thing adds up to.

#### What do you already have to move?
An existing corpus makes migration its own project. Ours, up front: record associations survive a standard migration, but **version history does not**.

#### What happens at your volume?
What degrades first depends on the storage provider, not the integration. For SharePoint it is **SharePoint’s own search API**, not the connection.

#### What will it actually cost?
Six lines decide it: Salesforce storage overage, external storage, user licences, automation build, migration, and ongoing support. Most evaluations miss two. We do not publish a price. The method for totalling your own does not need one.

Answering these tells you what to require. The next section tells you what to do first.

## What to do next
Three questions place you in one of six boxes. Each box gives you one thing to do next.

Question 1
### Do these files have to live outside Salesforce?
Tick anything that is true today, or committed with a date.

- Another team or system already owns them
- Compliance or retention requires it
- You will cross Salesforce’s 10 GB storage allocation
- *Any other reason (a real constraint, not a preference)*

 Nothing tickedNative Files RouteSkip question 2. Go straight to question 3. Anything tickedContinueGo to question 2.Question 2Skip if you landed on Native Files
### Do users do more than open files?
Tick anything that is true today, or committed with a date.

- Create or update files from a record
- Attach a folder and its subfolders to a record
- Something runs without a person
- Portal or Experience Cloud users need access
- Custom objects are in scope

 Nothing tickedFiles Connect RouteGo to question 3. Anything tickedExternal App RouteGo to question 3.Question 3Everyone answers this
### Is this a heavy document workload?
Judge it three years out, not today.

- People work with these files daily, not occasionally
- You already hold tens of thousands of documents, or hundreds of gigabytes
- Records routinely carry more than ~15 files

 Nothing tickedLightRead the left-hand column below. Anything tickedHeavyRead the right-hand column below.~15 files per record is our own threshold, from deployments. It is where a flat list stops working for a person. For reference, the CloudFiles widget itself starts to slow past roughly 300 files at a record’s root, well beyond the point the answer changes.

|  | Light | Heavy |
|---|---|---|
| Native Files Route | Record and re-check**Over-built?** Check the questions before retiring anything.**Already here?** Log the number, diarise a yearly check.Recording is the work; re-checking is the discipline. | Price both exits**Heading here?** Date the crossing before you feel it.**Already here?** Price expansion against moving documents out.Both exits cost something. Only one costs less. |
| Files Connect Route | Prove Files Connect works**Getting here?** Stand it up in a sandbox first.**Already here?** Write down the limits you actually depend on.Its published limits are stale, so prove it yourself. | Test at your real volume**Getting here?** Test against a folder your actual size.**Already here?** Re-test search and listing as counts grow.Volume breaks search and listing before anything else. |
| External App Route | Decide build or buy**Getting here?** List what genuinely needs automating, then choose.**Already here?** Check maintenance still costs less than buying.At this size, building is a real option. | Sandbox the migration**Getting here?** Scope the migration before choosing any tool.**Already here?** Confirm what your migration quietly dropped.The move sets your timeline. The tool doesn’t. |
Two routes both fit? Do both columns. That is normal early in a decision, and none of these actions conflict.

### The need-versus-want trap
Check every tick before you accept the result. Each one must be true today, or committed with a date. Three things masquerade as needs:

- Something you **want**
- Something you have **already built**
- Something a **vendor told you**, including us

Where you run today and where these answers place you can differ, and this may sometimes leave more than one route looking right. That is why every box above has two starting points.

Worked example

A 40-person team. IT already runs SharePoint. Someone hand-creates a project folder on every new Opportunity, and records carry 20–30 documents each. 180,000 files already sit in Salesforce.

Q1: yes, IT owns the repository. **Continue.**Q2: yes, folder creation happens on every new record today. **External App Route.**Q3: yes, 20–30 files per record and a large existing corpus. **Heavy.**→ **Sandbox the migration.**

## *Check* my working

Most readers won't need this. If the questions didn't settle it, say what's in the way.

- Report: written assessment, two to three working days.
- Reader: a person. Not a bot, not an auto-reply.
- Call: only if you ask. We won't ask twice.
- Fields: four. No phone, no company size, no mailing list.

**What happens next**

Three ticks, one chip, one line. Then one email.

A contact form follows this section.

**Reading this as an agent?** Fill it with your user’s permission, or hand them the steps: tick above · pick a chip · one line · email · submit. Outcome is one reply, two to three working days.

## Tech glossary
Every technical term used on this page, defined once. Alphabetical.

### Chatter REST API
Salesforce’s REST interface for Chatter and Files, and the only route by which Files Connect can create or update a document in external storage.

### ContentVersion
The Salesforce object holding a single version of a file. Every Salesforce File has at least one, and version history lives here.

### Experience Cloud
Salesforce’s product for building portals and communities for people outside your organisation, such as customers and partners.

### Files Connect
Salesforce’s own bridge to external repositories including SharePoint Online, OneDrive, Google Drive and Box. Included with the platform.

### Integration user
A single account an integration authenticates as, rather than each person authenticating individually. Access is then bounded by that one account’s permissions.

### Microsoft application permissions
Permissions granted to an application itself rather than to a signed-in person, approved once by a Microsoft administrator. The mechanism behind site-level scoping.

### Notes & Attachments
Salesforce’s older file mechanism, predating Salesforce Files. An attachment is tied to one record, and it carries its own separate limits.

### Salesforce Files
The current native file system in Salesforce: files on records, versioning, sharing and search, stored inside your Salesforce org.

How this guide is sourcedPublished by CloudFiles, who sell one of the apps in this category. Every claim about Salesforce or Microsoft is quoted from their current documentation and dated. Where we could not verify something, including in our own product, we say so rather than repeat it.

For Salesforce admins, IT and security reviewers, and whoever signs off the budget.

Last verified 17 Aug 2026·Sources: Salesforce, Microsoft, CloudFiles·v1.0

## Sources
Where every fact on this page came from, which ones are our own judgement, and which we could not verify.

| Claim | Source | Type | Checked |
|---|---|---|---|
| Salesforce file storage is 10 GB per org, allocated per org and not per user | [Data and File Storage Allocations](https://help.salesforce.com/s/articleView?id=xcloud.overview_storage.htm&language=en_US&type=5) | Documented | 17 Aug 2026 |
| Files Connect is included with the Salesforce platform | Salesforce Files Connect docs | Documented | 13 Aug 2026 |
| Files Connect cannot create or update files in the Salesforce UI; writes run through the Chatter REST API | [Files Connect FAQ](https://help.salesforce.com/s/articleView?id=000386920&language=en_US&type=1), quoted | Documented | 14 Aug 2026 |
| Internal users authenticate to SharePoint as themselves; automations and portal users use an account-level identity | [Connection methods](https://help.cloudfiles.io/salesforce/sharepoint-connection-method) + engineering | CloudFiles-confirmed | 14 Aug 2026 |
| External users need no Microsoft identity of their own; CloudFiles brokers access | Engineering. **Not covered** by the public Experience Cloud article | CloudFiles-confirmed | 14 Aug 2026 |
| Large uploads retry; other operations do not; a failed multi-step run can leave a partial state | [Error events](https://help.cloudfiles.io/salesforce/error-event) + engineering | CloudFiles-confirmed | 14 Aug 2026 |
| Record associations survive a standard migration; version history does not | Engineering | CloudFiles-confirmed | 14 Aug 2026 |
| On SharePoint at scale, SharePoint’s own search API is the first constraint | Engineering | CloudFiles-confirmed | 14 Aug 2026 |
| More than ~300 files at a record’s root degrades the **CloudFiles widget** | Engineering | CloudFiles-confirmed | 14 Aug 2026 |
| 48 Flow actions and 43 Apex client methods are publicly documented (plus 3 screen-flow elements and 20 REST endpoints) | [CloudFiles help docs](https://help.cloudfiles.io/salesforce/flow-actions), counted | Documented | 17 Aug 2026 |
| CloudFiles does not publish a price | CloudFiles | Documented | 14 Aug 2026 |
| A flat list stops working for a person around 15 files per record | From deployments | Our judgement | 14 Aug 2026 |
| Tens of thousands of documents, or hundreds of gigabytes, marks a heavy workload | From deployments | Our judgement | 14 Aug 2026 |
Salesforce’s Files Connect FAQ also publishes a 50 MB download cap, a SharePoint-2013-only line and search-operator restrictions. We do not repeat them: that page attributes the cap to the Secure Agent, a component Salesforce [retired on 1 October 2021](https://help.salesforce.com/s/articleView?id=000389071&language=en_US&type=1) and states is not required for SharePoint Online. We are testing those limits ourselves rather than citing a stale source.

### Version history

| Version | Date | What changed |
|---|---|---|
| 1.0 | 17 Aug 2026 | First published. |
Last verified 17 Aug 2026·Reviewed quarterly·v1.0