How to setup your Salesforce API user for a scalable design

What is an API user – or integration user?

---

An API user is also sometimes called an integration user. This is a technical user created and shared with an external application in order to grant access to Salesforces APIs and to a specific set of ressources (objects, fields, CRUD permissions…).

Having a dedicated user for integration/extraction purposes is a best practice, as real users might leave one day your company and you would probably want your integration to keep on working, and also this allows you to granularly control the security and authorization you want to grant to this technical API user.

For instance, why such API user would have access to the User Interface? Why such API user would be able to View All or Modify All while it only needs to be able to update one field in one custom object? Imagine one second this access falls into the wrong hands, this is a serious security breach…

As a first step, take a look into this Salesforce article.

On top of these recommendations, I’d additionaly add the following Dos and Don’ts; in order to ensure a sustainable setup and promote reusability over the time.

These is a general guidance, and should be adapted to your context.

Dos: Recommendations to have a secured and scalable design for your integration user

---

• Dedicate one custom profile for all API users (will serve integrations and extractions)
• Configure it by default with no access to all objects
• Have one different integration user for each external application/requirement interacting with your Salesforce org
• Assign all integration users to the same integration profile using a Full Salesforce licence if possible
• Create one Permission Set by external application or requirement
• Grant Field Level Security to the API users only through permission sets, as well as specific system and application permissions
• Assign the Permission Set to the corresponding user

Don’ts: Avoid the following design for your API user

---

• Use a system administrator profile to provide access to external application unless absolutery necessary – The system admin profile has extra authorization bypassing every sharing rules and permissions. The external system would be able to access and modify data it might not be authorized to, whether intentionally or inadvertently.
• Create a profile by external application. This is not a best practice as this would drive having different profiles for different external application with too few users assigned. This will be flagged as bad practice by the Salesforce Optimizer Report. Leverage Permission Sets instead.
• User the same profile / permission set / user for many external application or business requirements. I believe this make more difficult the maintenance over the time : who will remember that this CRUD on this field is used by only one or many external applications? This will also complexify issue troubleshooting: when using debug logs how will you easily target the external application you want to among all logs generated at the user level?

What are the benefits for your integration and its maintenance over the time?

---

Leveraging Permission Set make your administration more scalable when new interfaces are coming up on the org. You just have to create a new dedicated user and permission set, much more easy than a full profile.

Maintenance will be easier if you can easily identify the Permission Set that needs to be changed, without worring about impact it could have on other external systems.

Troubleshooting will be more granular, as each API user will represent a specific business requirement / external application.

Security is clearly improved as you just open up the required permissions through a Permission Set.

Have you found this interesting? Please share!

---