As a security-minded admin, you should follow the principle of least privilege. What is the principle of least privilege, you ask? It’s the concept of limiting users’ access rights to only what is required to do their jobs. That’s always been my guiding principle as an admin, and even when I was a customer. Following this principle does take discipline and patience.
If you’re using the Salesforce API Only System Integrations profile for the first time, I highly recommend you configure this in a sandbox before implementing in production. This is because you want to perform thorough testing in a safe environment before potentially negatively impacting your production data.
Note: Not all integrations work with this license. Check with the vendor/provider. You may not be able to assign a managed package permission set based on the permissions granted to the integration user.
The easiest way out when it comes to setting up access for a new integration is to use the System Administrator profile. Easy peasy. In fact, there have been several times in my career when trying to work with vendors on least privilege access for the integration user where their answer is to give system admin access. WRONG! When challenged, you’ll find that most of the time, the integration works just fine without giving the keys to the kingdom with the System Administrator profile. There was the rare occasion where the integration needed to be assigned to the System Administrator profile for the integration to work (it appeared they looked for the specific profile name on their end).
My recommendation: Start by establishing a new user for each integration, assigned to the Salesforce Integration user license. The Salesforce Integration user license creates the Salesforce API Only System Integrations profile and Salesforce API Integration permission set license available for assignment. Enterprise Edition, Unlimited Edition, and Professional orgs are automatically provisioned with five Salesforce Integration user licenses at no additional cost. If you need more licenses, reach out to your account executive (AE). API Only means the user can only access Salesforce via a REST, SOAP, or Bulk API and not through a user interface.
If you use the same user account across multiple integrations, you’re most likely opening an integration to have more access than needed, and thus, not adhering to least privilege access. It also minimizes security impact if the user or integration is compromised.
With a dedicated integration user, you can really lock down your integration to what it truly needs access to, including login IP ranges. Think about which permissions are necessary for its job to be done.
Under Company Information in Setup, you’ll find the Salesforce Integration under User Licenses and the Salesforce API Integration under Permission Set Licenses.
Here’s an example of an integration user assigned to the Salesforce Integration user license. Upon user license assignment, it populates the profile with Salesforce API Only System Integrations.
Once you verify the new account, rather than log you in to the org, Salesforce shows a note that access is restricted for API Only users. For all subsequent logins, the REST, SOAP, or Bulk API must then be used.
Given that permissions on profiles are slated for end of life in Spring ’26, the go-forward model for user access control is persona-based with use of permission sets and permission set groups. The profile should only be used to control defaults, page layout assignments, login hours and IP ranges, and the all-important API Only permission.
With this end goal in mind, I strongly recommend you edit your Salesforce API Only System Integrations profile and strip all permissions from the profile itself. Use permission sets and permission set groups to extend the other permissions, such as user permissions, object and field permissions, connected app access, and much more.
In an ideal world, you wouldn’t need to take this step. The Salesforce API Only System Integrations profile should be bare bones to start. Note: There’s currently a known issue with the Salesforce API Only System Integrations profile adding more permissions upon creation in the org.
Additionally, you will need to assign the Salesforce API Integration permission set license to your integration user. The Salesforce API Integration permission set license, in a nutshell, contains all the permissions you would find in the standard System Administrator profile that were lifted and moved to a permission set license instead.
What’s the difference between a permission set license and permission set? Think of a permission set license as additional permissions above and beyond the permissions already granted by your user license. A permission set is a subset of permissions granted to a user assigned to the permission set. If you assign users permissions via a permission set and they don’t have the required licenses, you receive an assignment error.
Let’s say Mochi (my pomeranian) is assigned to an animal user license that does not allow her to have zoomies and eat dog treats, but she needs to be able to have both. Mochi is assigned to a dog permission set license that gives her the ability to have zoomies and eat dog treats. However, for Mochi to actually have zoomies or eat dog treats, she needs the two permissions granted to her via a permission set.
In the case of our integration user, we have assigned it to the Salesforce Integration profile (user license), which only has the administrative permissions: API enabled, API only user, and Chatter internal user enabled. It has no access to standard or custom objects. To grant an integration user additional permissions needed, we extend the functionality access via the Salesforce API Integration permission set license. If you need to grant access to read and edit contact data, you would grant this access to the integration user via a permission set.
Note: When creating a permission set, when you select a specific permission set license, any user assigned to the permission set is auto-assigned the permission set license. If you select —None—, you must manually assign the permission set license to users before you can add them to the new permission set.
To view all the permissions associated to the Salesforce API Integration permission set license, locate the permission set license on the Company Information page in Setup. It will then take you to a page that lists all the permissions granted in this permission set license.
Follow the admin best practices for user management to grant the needed permissions to your integration users. Excluding your defaults (record types and apps), page layout assignments, and login hours and IP ranges, create permission sets and permission set groups to extend access to your integration users. Bundle permission sets into persona-based permission set groups for ease of user management. With permission set groups, you can reuse your permission sets and use the muting feature in the permission set group to remove permissions from permission sets that do not apply to the users assigned to the permission set group.
So, which permissions you should grant your integration users? Well, it depends. One integration may need Read/Edit access to your account and contact data. Another integration may need Read access to your user data as well as access to create activities. You’ll need to work with the integration provider to determine the least privilege access for that integration user. Check with the provider/vendor—they may have this information already documented in a setup/user guide.
Based on your use case, your integration user may also need additional permission set licenses, in addition to the Salesforce API Integration permission set license. If you run into an issue where you are unable to assign a specific permission set license, open a case with Salesforce Support indicating that you are unable to assign the specific permission set license to a user with the Salesforce Integration user license.
Before you make these changes in production, please do thorough testing of the new integration profile, permission sets, and permission set groups configuration in a sandbox to ensure all works as expected. Experiment first with the bare minimum privileges. As you do your testing and identify issues, add more permissions to your permission sets until your integration can fully do its job with the permissions you granted it. Yes, sometimes this will be trial and error.
Finally, implement the changes into production. Verify no new permissions snuck into the Salesforce API Only System Integrations profile during its deployment/implementation. If so, manually edit the profile to remove permissions that the profile you tested with did not have. Spend a month monitoring the integration to confirm it has the necessary permissions. if updates are necessary, make the changes to the permission sets/permission set groups in a sandbox, test them, and deploy the changes to production.
If you’re moving an existing user to the new integration profile, permission sets, and permission set groups access model, I recommend keeping the previous model in place, in case you need to switch back in a pinch and delete the obsolete access model (that is, custom profile/permission sets) after 1 to 2 months of the integration running fine on the new access model.
What are Invocable Composer Flows? MuleSoft Composer is an integration tool designed for admins, business analysts, marketers, salespeople, and team leaders. Using Composer, you can quickly and easily build flows to integrate systems and data and automate integration tasks. It’s a no-code tool you can use to build automations with only clicks. To further supercharge […]
MuleSoft Composer is the fastest and easiest way to connect apps and data for business teams, in partnership with IT. With the long-awaited error handling feature that Muleys are excited about, you can build more robust and resilient automation. You can further automate your flows, get real-time notifications on failures, mark failed records for reprocessing, […]
Are you tired of waiting for IT resources to build out an integration to your supplier? Are you frustrated that your payroll system lacks reliable application programming interface (API) documentation, leaving your IT team to weed through JSON and just hoping it’ll work? Then Flow HTTP Callout is for you! This feature does the hard […]
