top of page
  • Writer's pictureDoug Merrett

Salesforce’s new Integration User Licence and why it’s good for security

TL;DR; Salesforce’s new licence is designed just for API users and at the low cost (5 free and only US$120/year for another licence) it will allow customers to stop sharing a user licence with APIs thereby making things more secure.


At TrailblazerDX 23, Salesforce announced that all customers with Enterprise Edition and higher will get 5 free Integration User licences in their org from mid March. The price for extra licences, if you need more than 5, is good value at US$120/year each (at present).

Why is this good for security? It will allow Salesforce customers who do integration to stop piggybacking on a human user. This was done by many customers as the cost for an integration user in the past was the same as a human user. The new licence is so much cheaper that you should be able to afford an Integration User licence for each of your external integrations.

In most of Security Assessments I do for Salesforce customers, the number one issue I find is that they are using human System Administrator accounts as API users as well.

My article Don’t use the System Administrator profile for Integration Users in Salesforce explains the reasons for not doing this — the main one is that the system at the other end of the integration most likely has your credentials and you have probably set the password to never expire. Since it is a System Administrator, if someone gets these credentials, they can run roughshod all over your system — delete objects, modify data, deploy new applications, create users, … the list goes on.

So, having 5 free licences for API users, you can now create a user for each external system that needs access, and most importantly, set the appropriate permissions for the objects and fields needed for that external system.

For example, if you have an external system for accounting, it will need to let Salesforce know that an invoice has been paid — the API user for this integration would just need read and edit access to the Invoice object and for the field level security, it would need read access to the Invoice Id (or Invoice Number if it is an External Reference), as well as, read and edit access for the Paid checkbox (or Date Paid field depending on how you do this). Just that one object and two fields — that’s it. This means that if the credentials are stolen they cannot do any damage that you cannot fix, as you should be using Field History Tracking on this important field and you could see when and who updated the values to reverse these if needed.

49 views0 comments

Recent Posts

See All

Java, WSC, JWT and Connected Apps

You should not be using Username/Password authentication for API access - let's have a look at how to use JWT and Salesforce's WSC to do it.


bottom of page