A Salesforce Administrator’s Journey: today I learned about Integration Accounts

Salesforce is big. Even as a qualified administrator I feel like I’ve only just scratched the surface of all the nuances that impact a day in the life of… So this blog is a collection of all the little things that I learn and relearn on a daily basis.

Today I learned about Integration Accounts. An integration account is a dedicated Salesforce User record that is used to provide login credentials and manage security access for 3rd party applications.

The advantages of using integration accounts are that they are not attached to a specific User. If, for example, you used your own account as an Integration account then there would be no way to separate your actions from the actions of the 3rd party integration. This could make you liable for changes that you did not make. If you left the business and your account was de-activated or frozen then this may affect the performance of the 3rd party integration and break functionality. This might not affect you as the administrator that leaves but if, like me, you believe in karma, then think about your successor and hope that no one does this to you as you join a new organisation and have to fix all their broken integrations!

Integration accounts are a must but how do we set them up? What is best practice and how many integration accounts should we have?

Setup

There are few hard and fast rules but there are some common sense guidelines to consider. You setup an integration User just like any other User account BUT best practice is that you use a shared email address as the registered email address for the integration user account. This means that no one ‘owns’ the User account so any changes such as password resets (or someone attempting to change the email address itself) will be sent for verification via that email address. Assuming the email address is monitored then this should prevent any accidental or malicious changes to the account that might break an integration (or worse, allow a nefarious individual to leverage the account).

It is also wise to establish a naming convention, especially if you go down the route of having multiple integration accounts (more on that later). For example, I set the First Name to be the name of the integration i.e. ‘Pardot’ and the Last Name to ‘Integration’. This makes searching for integration accounts a bit easier. It also makes sense to set the Username to something something similar i.e. pardot.integration@mycompany.com.

Next you have roles and profiles to consider. Now this goes a bit outside of the scope of this article but best practice is to setup a dedicated role and profile that provides the bare minimum access required for the integration. Obviously you can add permission sets to the User to expand on access once you’ve set the minimum base line. This would most likely mean providing just Read Only access to start with. Again, you can give create/edit/delete access via permission sets as required. If you go down the route of using multiple integration accounts then you can name the permission set based on the integration. Perfect.

One Account to Rule Them All

Well, no. Maybe. There is no Lord of the Rings Analogy to be had here. Not a good one anyway. So, here’s a list of pros and cons for having one single integration account for all integrations vs. one account per integration:

Pros of the single account

• Only consumes one licence
• Easier to setup and manage; one role and profile, one set of credentials to keep safe and change when someone leaves, no need for permission sets

Cons of the single account

• Less control and security; all integrations must have same access levels
• Harder to audit and troubleshoot; you don’t know which integration makes a change

Pros of one account per integration

• More control and security; unique permission sets give each integration the exact access required
• Easier to troubleshoot; you know the exact integration responsible for a change

Cons of one account per integration

• Uses one licence per integration
• More admin overhead; lazy admins

Hybrid Theory

OK, stop trying to put me in a box — there is a third option. You can use a combination of the above. It takes a bit more planning but if you have some integrations that require, for example, Read Only access then they can all be on the same integration account. Then you can decide how many more accounts you’d need to give your remaining integrations the access they need without allowing them to do things they shouldn’t do. Life is all about compromise. That’s what my wife tells me and I believe her.