Best Practices for Managing Salesforce Users
Managing Salesforce users doesn't seem like a big deal but believe it or not, there are best practices for managing Salesforce users. Incorrect management of users and licenses can cause data integrity issues in the org among other things. Best practices apply to every area of Salesforce and user management is no different.
So, here are some best practices, along with a few tips and tricks, that I've found to be beneficial - making user management much easier!
Don't Update, Deactivate!
When Bob, a sales rep, leaves your organization and Jane is hired to replace him, it seems logical to edit Bob's user account with Jane's information. The problem with this approach is that everything, EVERYTHING, that Bob created or owned in Salesforce now belongs to Jane. It's as if Jane is the one that created or modified these records.
A data integrity issue is now created. We no longer have a clean history of what Bob did in Salesforce.
Now, let's say that Bob's account was updated with Jane's information, and a few months later, Bob is rehired and needs access to Salesforce and Jane is still an active Salesforce User. Oops! That's a big problem!
When a user no longer needs Salesforce access, their user account should be marked as inactive. The Active checkbox on the user's account should be unchecked. This will do three things:
- Prevents that user from accessing Salesforce.
- Keeps Salesforce data intact.
- Allows the Salesforce license to become available for allocation.
If this approach was used in Bob and Jane's example, Bob's inactive account would still be allowed to own records in Salesforce until they could be transferred to an active user, and Jane would have the ability to start fresh. And, when Bob returns, the Salesforce Admin simply needs to reactivate his Salesforce account by ticking the Active checkbox!
If you're worried about licenses, don't be. Only ACTIVE users count towards your total number of licenses, not inactive users.
Deactivate Users in Sandboxes
Salesforce Lightning Edition upgrades, which have hit every org with the Summer '16 release, now have a HUGE number of sandboxes to leverage for migrations, training, testing apps and change management. This is a really good thing!
But, when a user is deactivated in your production environment, that user is not deactivated in any of these sandboxes. Orgs that use a Partial or Fully Copy sandbox should be extra diligent because these sandboxes contain client and other business information.
There may be an occasion when a user needs to be quickly deactivated so that their access to this customer information is swiftly removed so that it can't be stolen last minute. If this user has access to a sandbox, especially a partial or full copy sandbox, Admin's need to also deactivate the user there. While the likelihood that the user is aware of the sandbox is very low, it can still prove to be an active access point to steal some data.
Easily Identify Inactive Users
Because users can't be deleted from Salesforce, inactive Salesforce users may still own records. As time goes on, current employees may have never met that user, and in large organizations, may still think the user is an active employee.
As a Salesforce Administrator, we can pull reports and create list views to see who is an active or inactive user, and users can click on an employee's name to check the status of the employee, but this creates multiple, and sometimes unnecessary clicks.
To simplify this process, when deactivating a user, I like to add the word Inactive in front of the user's first name. Now, whenever a user, including myself, runs across the inactive user in Salesforce, I know straight away that the user is no longer active.
So, Bob Jones becomes Inactive Bob Jones.
Don't Transfer Every Record
When a new user is added to Salesforce or territories are reassigned, or some other event that requires a record transfer takes place, it's important to determine what records should, and shouldn't be transferred.
Let's again visit our users Bob and Jane. When Jane is hired to take over Bob's territory, the Salesforce Admin should ensure that Bob's account is inactive, and a brand new account is set up for Jane.
Jane will now become the owner of Bob's records. But caution should be used. While Jane is taking over for Bob, it's still important to see what Bob did on these accounts. So, only active records should be transferred.
The below table outlines some general guidelines and recommended best practices for the core Salesforce objects.
| Object | Transfer | Don't Transfer |
|---|---|---|
| Leads | Active Leads | Leads that have been marked as dead, unqualified, etc. |
| Accounts | Active Customers and Prospects | Inactive Customers |
| Contacts | Contacts related to Active Customer Accounts or Active Prospect Accounts | Contacts related to Inactive Customer Accounts |
| Opportunities | Open Opportunities | Closed (Won or Lost) Opportunities |
| Activities (Tasks & Events) | Open activities that still need to be completed | Completed Activities |
Notice that records which are not active and are considered historical are not transferred. In our example, Bob, an inactive user, would continue to own the records in the Don't Transfer column. He is the user that took specific actions to close or update these records accordingly, and it's important for Jane and others to know who took actions on those records.
As a result, Jane now owns actionable data. Everything that is transferred to her is open and active which provides her a place to focus as she get's ramped up.
And, if an old lead owned by Bob comes back and wants to reevaluate your business, Jane can then take ownership of that old lead and update the Status accordingly.
It's important to note that transferring records will depend on your business. There may be a use case to transfer some of the records in the Don't Transfer column. If that is the case, be sure that the reasoning is documented someplace.
What About System Admin Users?
Oh, those pesky System Admin users. They are tied to so many important processes that it's hard to determine when they can be deactivated. Well, you're in luck because I published a post specifically on how to handle these users! Here's the post - Deactivating a Salesforce Administrator.
While this is not a comprehensive list of user management best practices, these are some biggies. If you have some best practices or tips and tricks for managing users in your org, leave a comment below!
