Salesforce announced a new affordable API-only license
This is how and why you should use them
As you might have heard by now, Salesforce announced a new, more affordable license during Trailblazer DX23. This new license became available in different Salesforce orgs on March 14th. In Salesforce Developer instances, one license should be made available (alas, I have yet to see it in any of my developer instances). Additionally, in paying orgs, 5 free Salesforce Integration licenses should exist free.
You can quickly get more licenses for only $10 / per user. This will give quite a few integration users before you reach the price tag for a fully-priced user license.
You can easily see the current license status in your org by navigating to “Setup” and the “Company Information” page, where the available licenses will be displayed.
Why is this a thing at all? This will help Salesforce administrators to get more easily maintained orgs that have better tracking and are more secure. You may wonder how this could be. Let’s look at a typical use case today.
How you may be doing things before this announcement
In the worst case, the administrator of the Salesforce instance will use their account as the user the integration is using. The Salesforce Administrator profile will give the integration full access to all data making the setup easier. However, there are multiple problems with this approach.
If the administrator leaves the company, the admin account cannot easily be deactivated. As a result, all integrations will have to be reconfigured. This requires time and effort, and it is sometimes scary to modify currently live and working integrations. Why touch something that works, risking breaking it?
A potential credential leak or security incident with the third-party application could provide access to data in the whole Salesforce instance. Such a leak will also be difficult and time-consuming to fix since many integrations must be reconfigured in a security breach.
When changes to data happen, it is impossible to know if it was the administrator or any, and if so, which integration is causing the data change. This might sound small, but knowing who did a specific change will help troubleshoot strange issues. Sometimes you may also run into audit and regulatory issues needing unique users.
You could say; my company does not use user accounts for integration. Instead, we have one dedicated integration user for our integrations. This is better, but not good. Almost all the significant issues with the integration accounts mentioned above still apply.
Best Practice
The best practice is to have a dedicated user account for every integration. This user account should be configured to only be able to access what is needed in the integration, nothing more. By doing it this way, we solve most of the problems and limit the risks of data and access leakage when security incidents happen. And yes, trackability is also increased.
This small announcement will significantly impact the security practice if implemented.
How to set up a user with this new license type
I am probably not the most intelligent guy out there, but I didn’t get it to work straight out of the box. I got a user created but couldn’t assign it any sensible permissions. But after some work, I got it to work, and it is not hard when you know how to do it!
Start by creating a new permission set. Give it access to all the objects and fields the integration needs. I prefer to make a permission set not tied to any specific license type. Sometimes this is a process of trial and error since it can be hard to know the exact field-level security that is necessary. But take the time here to get a permission set that gives access to precisely what the integration needs, not more.
At this point, it is also an excellent opportunity to consider what data in the different objects the integration may need. This can be done by granting “view” or “modify all” in the profile, but be restrictive. If access to all data is unnecessary, do not give it.
You can provide data access by using “sharing”. This could be done using roles, groups, or custom sharing. Do this as you would give data access to any other user.
When that is done, you either create a new user with the new “Salesforce Integration” license and the “Salesforce API Only System Integration” profile or change the license and profile of an existing user to these. You can also add the user to the correct role and into the right groups to provide the necessary sharing.
If you choose to create a new user, you can only log in and set the password via the UI. All other UI access is blocked for these licenses.
Then the tricky part comes, and you must do this before adding your new permission set. First, give the user the “Permission Set License Assignment” called “Salesforce API Integration”. If your user does not have this license assignment, you will receive an error while adding your custom permission set.
Adding your custom permission set to the user will be the last step to set the user up.
Then you repeat these steps for each integration, giving them individual users. All with just the access they need, not more. This will provide you with a setup that will work well even if an administrator is leaving, and it will protect you, as much as possible, against unnecessary data leaks in case of a security break at one of the integration vendors.
Good luck!