• Doug Merrett

Don’t use the System Administrator profile for Integration Users in Salesforce

Using the System Admin profile for an integration is very dangerous as you have given the other system complete read, write, create and delete capabilities for your entire system — all data and attachments/files. I have seen too many times that people take the easy route to integration with Salesforce and just use the System Administrator profile — why? It is just so easy; there are no sharing issues, the integration will have no permission issues, all the data will be available, it just works. However this is a very slippery slope. Giving an external system, probably not under your complete control, full access to your Salesforce data is dangerous. Even more so if you are “multiplexing” access for many actual users on the same connection.


Let’s discuss the first real issue — unfettered access to everything.

Using the System Administrator profile, will allow complete access to everything. You should not do this. Security is all about least privilege access. Give the integration user just the right level of access to the data, just like a regular user. Limit the integration user to only the objects needed and also use field level security to limit it to also just the fields necessary. To alleviate access to records caused by sharing, either set the integration user’s role to “CEO” to make sure they can see every record. Is the integration just reading data? Then do not give it access to edit, create or delete. The simple reason to do this is to protect your precious data from theft/corruption by a rogue integration or a bug in the other system. Or the manager of the other system leaks the credentials and “anyone” can then get unfettered access to your data. You should also add the “API Only” permission to minimise the ability for this user’s credentials being used by a human and logging into the Salesforce UI. And don’t forget that a System Administrator profile account can also get all your metadata and your Intellectual Property and even deploy changes into your Salesforce instance. Do you really need to hand all this over to an external system?


The next issue is using a single integration user as a “multiplexor” to allow many users to access Salesforce via one licence.

This has at least one serious security issue, one serious technical issue and (most likely) one serious legal issue when using this integration pattern.

Let’s cover off the security issue first: If you are using only one “user” as a front for many users, then you are having to keep all the data separate in your external app. All the inherent Salesforce security is moot, so a bug in the external app could easily expose all your internal data. Also you have no idea who is accessing which records in the Salesforce environment and it makes forensic investigation “impossible” using the Salesforce Event Monitoring logs… You will never be able to know who read which records and who deleted/updated which records.

Now the technical issue: you may hit the API Query Cursor Limit of 10 open cursors. See for the documentation. If you have more than 10 concurrent users or more than 5 concurrent users using 2 cursors each, then you will likely hit this fatal error.

And last but not least, the (probable) legal issue: you are not allowed to use a technical bypass to circumvent the Salesforce licencing. Technically, you need a licence for each user that is accessing the Salesforce environment. Have a look at the Salesforce MSA section 3.4(g) I am not a lawyer and therefore can not be sure of my reading of this and you may have negotiated a different MSA, so please check with your legal team to be sure.


Thanks for reading. Please provide any comments or feedback and ask any questions in the comments below. Thanks to Adam Best for suggesting an update to add the “API Only” permission.

20 views0 comments

Recent Posts

See All