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.
Files stay in Salesforce. Nothing to set up. Storage is capped per org.
Read SharePoint from a record. Free, but it needs configuring and stays read-only.
Folders, 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.
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.
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.
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.
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 1Do these files have to live outside Salesforce?
Tick anything that is true today, or committed with a date.
Do these files have to live outside Salesforce?
Tick anything that is true today, or committed with a date.
Question 2Skip if you landed on Native FilesDo users do more than open files?
Tick anything that is true today, or committed with a date.
Do users do more than open files?
Tick anything that is true today, or committed with a date.
Question 3Everyone answers thisIs this a heavy document workload?
Judge it three years out, not today.
Is this a heavy document workload?
Judge it three years out, not today.
~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.
That's with a person now.
You'll get a written assessment within two to three working days. No call unless you ask for one.
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.
Published 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.
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 | Documented | |
| Files Connect is included with the Salesforce platform | Salesforce Files Connect docs | Documented | |
| Files Connect cannot create or update files in the Salesforce UI; writes run through the Chatter REST API | Files Connect FAQ, quoted | Documented | |
| Internal users authenticate to SharePoint as themselves; automations and portal users use an account-level identity | Connection methods + engineering | CloudFiles-confirmed | |
| External users need no Microsoft identity of their own; CloudFiles brokers access | Engineering. Not covered by the public Experience Cloud article | CloudFiles-confirmed | |
| Large uploads retry; other operations do not; a failed multi-step run can leave a partial state | Error events + engineering | CloudFiles-confirmed | |
| Record associations survive a standard migration; version history does not | Engineering | CloudFiles-confirmed | |
| On SharePoint at scale, SharePoint’s own search API is the first constraint | Engineering | CloudFiles-confirmed | |
| More than ~300 files at a record’s root degrades the CloudFiles widget | Engineering | CloudFiles-confirmed | |
| 48 Flow actions and 43 Apex client methods are publicly documented (plus 3 screen-flow elements and 20 REST endpoints) | CloudFiles help docs, counted | Documented | |
| CloudFiles does not publish a price | CloudFiles | Documented | |
| A flat list stops working for a person around 15 files per record | From deployments | Our judgement | |
| Tens of thousands of documents, or hundreds of gigabytes, marks a heavy workload | From deployments | Our judgement |
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 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 | First published. |