Overview
This page defines the minimum permission set required by the integration/API user, the dedicated Salesforce account, the Salesforce↔CloudFiles integration authenticates and runs as. It also highlights the reasoning behind why each one is needed.
System Permissions
On the Salesforce Permission Set / Profile UI, these five permissions all live under the System Permissions category.
| Permission (Salesforce UI label) | Why it's needed |
|---|---|
API Enabled (ApiEnabled) | This is the standard permission required for any external system to access Salesforce data through the API at all. Without it, API calls from the integration are rejected outright, before any other permission or object/field access is even considered. |
Modify Metadata Through Metadata API Functions (ModifyMetadata) | Needed to build the customer-side flows and automations that CloudFiles sets up as part of your specific implementation. |
Use Any API Client Application (UseAnyApiAuth) | Allows the integration user to authenticate via the API without being restricted to a specific, pre-whitelisted connected/client application — necessary because the integration authenticates as its own API client. |
View Roles and Role Hierarchy (ViewRoles) | Automatically bundled in by Salesforce when Modify Metadata Through Metadata API Functions is granted — it comes along as a dependency, not something you enable separately. |
View Setup and Configuration (ViewSetup) | Automatically bundled in by Salesforce when Modify Metadata Through Metadata API Functions is granted — it comes along as a dependency, not something you enable separately. |
App Permissions
On the Salesforce Permission Set / Profile UI, these three permissions live under the App Permissions category, in the Flow and Flow Orchestration section — they're needed so CloudFiles can build, activate, and debug the customer-specific Flows that are set up as part of your implementation.
| Permission (Salesforce UI label) | Why it's needed |
|---|---|
Enable System Mode Flow Activation (ActivateSystemModeFlows) | Required to activate a Flow version that's configured to run in system context. Several of the Flows CloudFiles builds as part of your implementation run this way, so activating them needs this permission in addition to the general ability to activate Flows. |
Manage Flow (ManageInteraction) | Lets the integration/API user open, edit, and run a Flow regardless of whether it's currently active — needed while a customer-specific Flow is still being built or debugged, before it's ready to activate. |
Run Flows (RunFlow) | Lets the integration/API user execute active Flows directly — needed to run and validate the customer-specific Flows CloudFiles builds as part of your implementation. |
Apex Class Access
Separately, under the Apex Class Access category, the integration/API user needs access to essentially all of the CloudFiles managed package's Apex classes — these are the controllers that power the integration, so the account needs to be able to invoke them.
The simplest way to grant it is to assign the CloudFiles Minimum Access Integration permission set (cldfs__CloudFiles_Minimum_Access_Integration) to the integration/API user — it covers every class below, and it stays correct when the package is updated.
If you prefer to grant classes individually, these are the ones CloudFiles calls:
| Apex class | Why it's needed |
|---|---|
EnterpriseEventsController | Receives every event CloudFiles sends into your org, including file and attachment notifications. This is the one most often missed. |
SetupController | Used when connecting or reconnecting CloudFiles to your org. |
SettingsController | Reads and writes the package's settings, including user roles and the account region. |
DocumentMapperWriteController | Writes document-mapper results back to records, including the parent record and any child records resolved from a mapper run. |
PacketWriteController | Mirrors a Document Packet into your org when a packet is created from the widget. |
AbortJobController | Cancels the package's scheduled event-delete job. |
Object Level Access
On the Salesforce Permission Set UI, under Object Permissions, the integration/API user's permission set grants Object CRUD on the two objects the integration uses internally to track and process events.
| Object | Access |
|---|---|
cldfs__CloudFilesEvent__c (custom object) | Create, Read, Edit, Delete, View All Records, Modify All Records — full object-level access. |
cldfs__CloudFiles_Event__e (platform event) | Create, Read only. |
For organizations who are using the Document AI product, their integration user will need access on one additional object listed below:
| Object | Access |
|---|---|
cldfs__CloudFiles_DocAI_Run__c (custom object) | Create, Read, Edit, Delete, View All Records, Modify All Records — full object-level access. |
Under Field-Level Security, the permission set also grants Read and Edit access on the following fields of cldfs__CloudFilesEvent__c, which the integration reads from and writes to as it processes events:
| Field | Access |
|---|---|
cldfs__CloudFilesEvent__c.cldfs__Data__c | Read, Edit |
cldfs__CloudFilesEvent__c.cldfs__Object_Type__c | Read, Edit |
cldfs__CloudFilesEvent__c.cldfs__Request_Id__c | Read, Edit |
cldfs__CloudFilesEvent__c.cldfs__Type__c | Read, Edit |