Update Function Permissions

Salesforce permission sets are used to control which org data Salesforce Functions can access. When you deploy your function, make sure your function is associated with a permission set that has the correct data permissions.

All deployed functions invoked by an org use the Functions permission set in that org when making data requests. This permission set is automatically created when you connect your Dev Hub org with Salesforce Functions. Update the permission set to set data permissions specific to your function.

To modify the data permissions for your function, update the Functions permission set in the org that invokes the function. You can update the permission set using the Salesforce UI, or add a Functions.permissionset-meta.xml to your DX project’s force-app/main/default/permissionsets folder, with the desired data permissions. For example, give your function read and create access to the Account object in your org with the following Functions.permissionset-meta.xml:

After you update the Functions permission set in your DX project, deploy your changes to your org. When using scratch orgs, use the sf project deploy start command to deploy permission set changes (and other project-side changes) to your org. If you're collaborating with other developers and sharing an org and compute environment, make sure to merge your permissions changes with any changes your team has already pushed to the shared org. Retrieve changes to your project with sf project retrieve start first if necessary. For details on syncing project and scratch org changes, see Retrieve Source from the Scratch Org to Your Project.

For more information on Salesforce permission sets, see Permission Sets Overview.

When invoking a locally running function against a scratch org using sf run function start, the function uses the permissions of the current user, rather than the Functions permission set. The default scratch org user has System Admin privileges, but functions are called by the Cloud Integration User profile. Run your functions locally with a dedicated scratch org user with the minimum access to better test for real-world conditions.

Create a scratch org user using the Minimum Access - Salesforce profile. Create a permission set that provides the same object access permissions that your Functions permission set has, and apply this permission set to the new user. For more information on creating scratch org users, see Scratch Org Users.

From a permissions perspective, Apex code that invokes Salesforce Functions is no different than other Apex code. The code runs in system mode, as described in Understanding Describe Information Permissions. Functions invoked asynchronously with Apex work similarly. After the function executes, the Apex callback runs in system mode as the user that invoked the function.

Apex invocation can only invoke functions that have been deployed to a compute environment that is associated with the org the Apex code is running in. Apex code that invokes functions, like any Apex code, is considered "trusted code" in a given org, deployed to that org by someone that understands the security and permission requirements of that org.

Salesforce provides additional layers of permissions and security around who can execute Apex code, such as Author Apex permissions and Apex class security. Apply class security to your Apex code that invokes Salesforce Functions so only certain users can execute those classes. See Salesforce Help: How Does Apex Class Security Work? for more information on Apex class security.

When a deployed function is invoked, the function runs as the Cloud Integration User profile when making requests back to the org, not as the org user that invoked the function. Any data access permissions on the invoking user must work for the Cloud Integration User as well.

Data requests are checked against the Functions permission set. Set the object permissions in the Functions permission set to match the object permissions for the users that invoke the function. For example, add ViewAllRecords and ModifyAllRecords permissions if the function must view or modify objects.

See Give Users Access to Data for more details on setting data access permissions in your org.

Users with the Functions permission set assigned can run any function in their org. You can also create individual permission sets for specific functions. These permission sets can be activated directly from the function code while the function executes with a session-based permission set.

To create and use a session-based permission set, first update the existing Functions permission set so it can manage the individual function permission sets.

1. From Setup, in the Quick Find box, enter Permission Sets, and then select Permission Sets.
2. Click the Functions permission set and go to System Permissions.
3. Click Edit and select Manage Session Permission Set Activations.
4. Click Save.

Create a permission set to provide permissions when needed, like during invocation.

1. From Setup, in the Quick Find box, enter Permission Sets, and then select Permission Sets.
2. Click New and give the permission set a name specific to its associated function.
3. Select Session Activation Required.
4. Add any permissions to this permission set your function needs for execution, like Accounts in Object Settings if your function needs access to Account objects.
5. Click Save.

The Cloud Integration User profile is what your Salesforce Functions use to make API calls on behalf of the function. You can't assign the Cloud Integration User to a permission set in the Salesforce UI, so this step must be done on the command line.

Make sure you're logged in to your org via the Salesforce CLI and use SOQL to query the User object to find the username for the Cloud Integration User profile.

Copy the username from the output (the one with cloud@ at the beginning) and use it to assign the session-based permission set to the Cloud Integration User.

To assign a session-based permission set to the Cloud Integration User profile, you have to use the Salesforce REST API to make a request to activate it. Add this request in your function code.

In Node.js with JavaScript:

Add the deactivation code to your function to make sure the session-based permission set isn't active for the next invocation.

In Node.js with JavaScript:

In Java: