5 days until Dreamforce. Booth 536 is taking slots now, and the calendar fills first. Details
Buyer's guide · Question 8

What happens at your volume?

What degrades first depends on the storage provider, not the integration connecting to it.

For Salesforce admins and IT evaluating this at real, not demo, scale.

Last verified ·Sources: Microsoft, CloudFiles engineering, CloudFiles Files Connect test·v1.1
Where this claim comes from

Published by CloudFiles. That the connection routes through Microsoft Graph, and that Graph enforces throttling under load, is Microsoft's own published policy, linked below. That this is what actually degrades first for SharePoint specifically, ahead of anything CloudFiles adds, is our own observation, not independently verified.

Why the provider matters more than the integration

A connector or app sits between Salesforce and your storage provider. At real volume, it's usually the provider's own infrastructure that slows first, not the layer connecting to it.

For SharePoint, that connection runs through Microsoft Graph, and Graph enforces its own throttling: exceed a library's list-view threshold and Graph returns an HTTP 429 (“activityLimitReached”), regardless of which app is calling it. Our own observation is that this is what degrades first at real volume, not CloudFiles' link to it. That's a Microsoft constraint no vendor engineers around, which is also exactly why no vendor should claim to have solved it.

Source: Microsoft Graph throttling guidance. Retrieved 21 Aug 2026.

What we measured, once

One tenant, one day. Treat these as a data point, not a service level.

  • A new SharePoint site took roughly 13 minutes to become visible to search after creation.
  • A newly indexed filename took roughly 6–12 minutes to become searchable through Files Connect.

Both numbers come from a single Developer Edition org against a single Microsoft 365 E5 Developer tenant, on one day. They tell you these things aren't instant, not what to expect on your own tenant. Measure your own before you plan around either figure.

Separately, and asymmetrically: in the same test, we found no download cap up to 2 GiB, but uploads through the API are capped at 75 MB (Developer Edition; unverified on Enterprise). If volume growth means larger files, not just more of them, test the upload direction specifically.

Source: CloudFiles Files Connect test, Developer Edition, 17 Aug 2026.

What to ask any vendor

  • What did you actually test, at what document count, in what folder structure?
  • What specifically slowed down first: listing, search, sync, or something else?
  • Can I see that test against a folder my own real size, not a demo dataset?

What your answer means

Modest volume, nothing approaching tens of thousands of files in one folder: this rarely bites in practice. Don't over-weight it in your evaluation.

Large or fast-growing corpus: require the vendor's own test data against something close to your real size, not a features list or a demo with a few dozen files.

Where this stops

This page settles volume only. What you already have to migrate is its own question; cost is a separate one, in the guide.

Check my working

Most readers won't need this. If your volume is unusually large, 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

One chip, one line, one email.

What the page didn’t settle
Last verified ·Reviewed quarterly·v1.1