The core difference

When CloudFiles runs an automation that connects to SharePoint, no person is signed in to authorize it, so something has to prove to Microsoft that CloudFiles is allowed to act on your files. The two methods take opposite approaches:

  • Integration user: CloudFiles borrows a real, signed-in Microsoft 365 account.
  • Service principal: CloudFiles acts as its own application identity in your Microsoft Entra directory, with no person behind it.

That single choice, a borrowed user versus CloudFiles' own application identity, drives everything else: whether a licensed seat is consumed, whether the connection breaks when staff leave or security policies tighten, who has to set it up, and how actions appear in your audit logs.

Integration user

An integration user is a real, licensed Microsoft 365 account. An admin signs it in once from the Libraries page under the SharePoint section (the "Integration user" option), and every account-level automation then runs under that account and inherits its SharePoint permissions.

Because a person's account sits behind the connection:

  • It consumes a licensed Microsoft 365 seat.
  • MFA, Conditional Access, or a forced password change on that account can break automations, since they depend on that account's sign-in staying valid.
  • Offboarding the person stops every automation running under the account.
  • Automated actions are logged against a human in your audit trail.

It is the quicker option to set up: any admin who can sign in to the account can connect it, with no Microsoft directory administrator involved.

Service principal (app-only)

With a service principal, CloudFiles authenticates as its own application identity using the OAuth 2.0 client-credentials flow. A Microsoft Global Administrator grants the CloudFiles application consent once, which creates a service principal (the local record of the CloudFiles application) inside your own Microsoft Entra (Azure AD) directory. From then on there is no signed-in user, no password, and no token tied to a person, so none of the integration-user constraints above apply.

How it works in practice:

  • CloudFiles authenticates with its own certificate (a signed JWT client assertion) that it holds and rotates. You never create an Azure app registration, generate a client secret, or paste and rotate credentials. This also matches a Microsoft requirement: SharePoint Online rejects app-only tokens minted with a client secret for the SharePoint REST resource, so certificate-based authentication is the supported path for real SharePoint operations.
  • Access tokens are short-lived (on the order of an hour) and re-issued automatically, so no long-lived credential sits in your environment.
  • One consent covers both Microsoft Graph and the SharePoint REST resource, so the separate SharePoint REST API authorization step that older setups require goes away.
  • The identity, its permissions, and its consent all appear in the Enterprise Applications area of Microsoft Entra, where your admins can audit it, govern it, or revoke it like any other application.

The main setup consideration is that consent has to come from a Global Administrator, who is often not the same person as your Salesforce admin. CloudFiles generates the admin-consent link for your tenant so the Salesforce admin can pass it to IT to approve.

See also: for the step-by-step setup of each method on the SharePoint tab, see the SharePoint configuration guide.