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:

  1. Prevents that user from accessing Salesforce.
  2. Keeps Salesforce data intact.
  3. 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.

ObjectTransferDon’t Transfer
LeadsActive LeadsLeads that have been marked as dead, unqualified, etc.
AccountsActive Customers and ProspectsInactive Customers
ContactsContacts related to Active Customer Accounts or Active Prospect AccountsContacts related to Inactive Customer Accounts
OpportunitiesOpen OpportunitiesClosed (Won or Lost) Opportunities
Activities (Tasks & Events)Open activities that still need to be completedCompleted 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!

17 thoughts on “ Best Practices for Managing Salesforce Users ”

  1. I read recently that records owned by an inactive user will not appear in a report if they object has record types (this is regarded as a bug). That is another factor to take into account when deciding which historical records stay with the inactive user


    1. Hey, Don! Thanks for the comment. You’re probably referring to the fact that the “Active” or “IsActive” fields aren’t accessible in standard reporting. You can, however, create a custom report type to access these fields. Personally, I’ve always updated first names to include the word “Inactive” and used that as a filter in my reporting. Here’s the Salesforce Knowledge article that shows how to create this specific report type.


  2. Hey Brent! Thanks for sharing the knowledge. I have a quick question. What will happen if the dead leads comes back again as a new lead? Dead lead record is not transferred to Jane as it is still belongs to Bob. So now if we transfer that record to Jane now, we will loose the information what Bob did or what happened during that time when Bob was dealing with this lead and marked as dead.


    1. Hi Sudipta! To some degree, this comes down to business process and the metrics your business is attempting to track. In my past lives, we’ve allowed the dead or unqualified lead to be reassigned to a new owner (but not change any Activity ownership). This prevents duplicates, and ensures that we’re maintaining history in Salesforce. But, you may decide that there is a business reason to clone the record and start fresh. Something to think about internally.


  3. Great article! I especially like recommendation to prrepend the user’s name with “Inactive,” and plan to put that one into practice right away!

    One thing to remember when transferring records is that the related Activity History will stay in the prior owner’s name, unless one specifically updates the completed tasks, while Open Activities will be transferred to the new owner. This preserves the history of the record, but gives the new owner a follow-up reminder, as long as an open task is present.


  4. Hi Brent! Thanks for sharing your tips and tricks, as always very useful!
    I wanted to share a recent Inactive Owner use case from one of our GridBuddy clients (which allows you to manage records in Salesforce like in a spreadsheet): the admin created a grid of Accounts with Contacts where Contact’s Owner was inactive, and then with our Mass Update feature, was able to reassign those Contacts to the Account’s owner. She was very excited!


  5. Hi Brent! Loving this article! Something so basic, but if not maintained correctly can cause massive issues. Only practise I am not doing currently is placing the Inactive in front of the first name, so will definitely start to add this in to our process. Thanks for the idea!


  6. Great article. I’ve also started adding a custom Notes field on the user record in certain orgs to help document information such as “this is an integration user for XXX software” or “this user needs ‘View All’ privileges because XX. Since there is no “description” field on the user (or the profile) I’d be curious what other suggestions or cautions folks have about adding notes about users.


  7. Hey – how can we get the Active users only when i m searching with one user. Suppose i have one user have Chatter Account. so what i did is i have deactivated this user and again i have created same user with the full licence. so when i am seaching with this user i am seeing the both accounts as Active and inactive


    1. This is why I like to preface deactivated user’s first names with the word “Inactive.” That way, when I search for the user in Salesforce, I can quickly identify which users are active, and which are not.


  8. Hi all,
    From our side, we have created the Role ‘Inactive User’ and we change it on inactive users.
    we also have a report of Active users sent every fortnights to help the system admins double check this list.
    By the way, is there a way to automate users termination from an external database?


    1. I’m sure that if the appropriate User details are available via the API, you could probably deactivate a user in Salesforce automatically, but I’m not 100% sure. If you find out, I would love to know!


  9. What is the best practice for an admin user? We still have not deactivated an old admin from 2015 since he is linked to so many processes (in and outside of SF), reports, etc.

    I am nervous about making his account inactive.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.