Do people outside your org need access?
External users have no Microsoft identity of their own. Whatever brokers their access becomes your actual security boundary.
For Salesforce admins and security reviewers evaluating Experience Cloud or portal access.
Published by CloudFiles. The brokering mechanism described below is documented in our own help center, linked below, so verify the specifics against your own use case before relying on them.
Why this is a different question from internal access
Your own users typically have a Microsoft identity somewhere in the stack. Experience Cloud, portal and partner users usually don't; they exist entirely inside Salesforce.
For them to reach a file that actually lives in SharePoint or another external system, something has to broker that access on their behalf, since they can't authenticate to Microsoft themselves. That broker, not SharePoint's own permission model, is what actually decides what an external user can see.
What CloudFiles does here
- External users need no Microsoft identity of their own. CloudFiles brokers access with its own single, account-level Microsoft identity, the same credential used for automations.
- Visibility and allowed actions (view, upload, and so on) are configurable per external user or profile.
- Internal identity, by contrast, is covered on the identity page.
Source: Experience Cloud, Permissions section. Retrieved 21 Aug 2026.
What Files Connect does here, tested directly
Files Connect's own portal and guest behaviour, not CloudFiles', tested against a live Experience Cloud site. This page previously drew only on vendor and platform documentation, and now has direct evidence.
- A portal user (Customer Community licence, a real login, not an admin impersonation) can see external SharePoint files on a record and a
CONNECTED SOURCESsection, and is offered a button toConnect to Microsoft SharePoint Online. Content stays withheld until they authenticate themselves: the record shows a file exists, not what's in it. - An unauthenticated guest gets a login page and, on the underlying API,
403 API_DISABLED_FOR_ORG: no content from any source, and no public links exist to leak in the first place. Scope: this covers a default Experience Cloud site with guest page access never granted, which is the configuration most admins will actually have. A site with guest pages deliberately turned on could behave differently. - An undocumented prerequisite we hit in passing: creating a portal user fails unless the account owner already has a role assigned.
Source: CloudFiles Files Connect test, Developer Edition, 18 Aug 2026.
What to ask any vendor
- Exactly how is access scoped: per external user, per profile, or per org-wide default?
- When a partner or portal user is deactivated, what do they lose access to, and how quickly?
- Is there an audit trail of what an external user actually opened, separate from your internal users' trail?
What your answer means
No external users today, and none planned: skip this criterion entirely. Nothing below applies until that changes.
External users at any scale: get the brokering mechanism explained in writing, not summarized in a sales call, before you commit. This is where a vague answer costs the most.
Where this stops
This page settles external-user access only. Internal identity is its own question; what happens at volume is a separate one, in the guide.
Check my working
Most readers won't need this. If your external-access requirement is unusual, 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.