# SharePoint Permissions Reference

Every SharePoint permission CloudFiles can request, delegated and application-only, listed side by side with what each grants, why CloudFiles asks for it, and which ones are tenant-wide by default.

> Kind: Guide · Updated: Sep 11, 2026

## Overview

CloudFiles connects to SharePoint two ways: a delegated per-user connection (an individual user, or an admin-connected integration user) and an application-only Service Principal, typically used for automations. Each requests a different, specific set of Microsoft Graph permissions. This page lists exactly what each one requests, in plain terms and by name, in one place, rather than spread across the setup and troubleshooting docs.

> Least-access is not automatic on the Service Principal path. CloudFiles' application registration holds tenant-wide permissions by default. Scoping it to specific sites is a deliberate, opt-in step, covered under Application permissions below.

## Delegated permissions (per-user OAuth)

When a person connects their own SharePoint account, or an admin connects a shared integration user, CloudFiles requests these delegated permissions. Each is scoped to what that signed-in identity already has access to in SharePoint, not a separate, broader grant.

| Permission (as shown in consent) | What it grants | Why CloudFiles requests it |
|---|---|---|
| Maintain access to data you have given it access to | Keeps working in the background without the signed-in user present. | CloudFiles makes API calls to SharePoint on demand, as part of automated processes, even when the user isn't actively using the app. |
| Edit or delete items in all site collectionsUnderlying permission: Sites.ReadWrite.All (Delegated) | Create, edit, and delete SharePoint list items and documents. | Powers file and folder create, rename, move, and delete actions from Salesforce. Scoped to sites and folders the signed-in user can already reach. |
| Sign in and read user profile | Basic profile info and sign-in. | Provides single sign-on: CloudFiles verifies identity through Microsoft, so there's no separate CloudFiles password to set up. |
| Have full access to all files user can access | Read, write, and delete files and folders the user can already see. | The file-level counterpart to the site/list permission above, needed for file-level operations specifically. |
| Read the names and descriptions of teams | Read-only access to Microsoft Teams metadata. | Powers the Microsoft Teams integration feature. |
| Create teams | Create new Microsoft Teams on behalf of the signed-in user. | Powers the "create a Team" automation feature. |

See the full explanation, including why an admin consent step is sometimes required, on the SharePoint Permissions page.

## Application permissions (Service Principal)

For automations, CloudFiles authenticates as its own application identity, a Service Principal, rather than a signed-in person. A Global Administrator grants consent once; CloudFiles' application registration then holds these Microsoft Graph application permissions:

| Permission | Default scope | Effect |
|---|---|---|
| Sites.Selected | Nothing, until an admin grants specific sites | Lets CloudFiles reach only the sites an admin explicitly grants, one at a time, using a one-time PowerShell command per site. |
| Sites.Manage.All | Tenant-wide | Create, edit, or delete lists and items in every site collection in the tenant. |
| Files.ReadWrite.All | Tenant-wide, always | Read, create, update, and delete all files in every site collection, independent of Sites.Selected. |

> CloudFiles' application registration holds all three by default. Sites.Selected alone does not restrict anything: Sites.Manage.All and Files.ReadWrite.All must both be removed in the Microsoft Entra admin center before access is actually limited to specific sites. See Restricting CloudFiles Application Access to Specific SharePoint Sites for the exact steps.

## Which one is least-access

Neither path is least-access by default. The delegated path always mirrors whatever the connecting person, or integration user, can already see in SharePoint; it's naturally bounded by that identity's own permissions, which are often broad in practice. The application path starts tenant-wide and stays that way until an admin completes the restriction steps above. Once completed, it's the narrower of the two: access can be scoped to an exact list of sites, with no dependency on any one person's own SharePoint permissions.