# Which identity actually reaches your SharePoint?

> Every vendor connects Salesforce to SharePoint through some identity. Per User and Named Principal are two different security stories, and this page names which one CloudFiles uses and for what.

*Buyer's guide · Question 4*

## Which *identity* actually reaches SharePoint?

Every integration connects through some identity. Ask which one, and for which operations, before you ask anything else.

For Salesforce admins, IT and security reviewers.

Last verified 21 Aug 2026·Sources: Salesforce, CloudFiles engineering·v1.0 How this page is sourcedThe two identity models are Salesforce's own vocabulary, documented for Files Connect. CloudFiles' own model is CloudFiles-confirmed, not third-party verified, so ask us to demonstrate it against your own sandbox.

## The two models

|  | Per User | Named Principal |
|---|---|---|
| Who authenticates | Each person, individually | One shared credential for everyone |
| SharePoint's own ACLs | Preserved | Collapsed into one account |
| Onboarding cost | One step per person | None, after initial setup |
Source: [Define an External Data Source for SharePoint Online](https://help.salesforce.com/s/articleView?id=admin_files_connect_sp_online_xds.htm&language=en_US&type=5). Retrieved 21 Aug 2026.

## What CloudFiles uses
Internal users authenticate as themselves. Automations and portal users run on a single account-level identity, not per-person credentials.

That's two different security stories inside one product: your everyday user activity is individually attributable, while anything automated or anything coming through a portal shares one identity's permissions. Ask exactly which operations fall on which side before you assume audit attribution covers everything.

## What to ask any vendor

- Which operations run under my identity, and which run under a shared or service identity?
- If it's Named Principal, how are SharePoint's own permissions honored, or are they not?
- Does an automation ever silently fall back to the shared identity when per-user auth fails?

## What your answer means
**Per-user audit attribution matters** for every operation, not just interactive use: confirm in writing that automations don't fall back to a shared identity for anything you need attributed.

**Doesn't matter,** or only matters for interactive use: the simpler shared-identity model for automation is a reasonable trade, not a red flag by itself.

## Where this stops
This page settles identity only. Whether external, non-Salesforce users need access at all is [its own question](/salesforce/document-management/questions/external-user-access); how files attach to records is a separate one, in [the guide](/salesforce/document-management/guide#questions).

## *Check* my working

Most readers won't need this. If your identity 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.

**What happens next**

One chip, one line, one email.

A contact form follows this section.

Last verified 21 Aug 2026·Reviewed quarterly·v1.0