Like zombies in a late-night horror show, shuffling hordes of inactive users can wreak havoc on your Salesforce implementation. On the one hand, they have been deactivated and can no longer log in like active users. On the other hand, their ‘dead’ information lingers on in many forgotten places. This ghostly presence can haunt your org from beyond the grave!
That may sound a little dramatic, but inactive users do cause lots of problems for Salesforce Administrators. Once a user is created, they can be made inactive, but they can never be deleted. Over time, most orgs end up with more inactive users than active ones. There are over 50 different ways for an inactive user to remain connected to a Salesforce org. For example, inactive users can still manage active users, receive system emails, consume package licenses, remain team members, and serve as the running user for important enterprise systems.
These ‘zombie’ users can complicate release management, software development, technical debt cleanup, and org splits and mergers. They also pose multiple security threats. Tracking down and removing all the connections between inactive users and the Salesforce org can be a very complicated process, as they can be connected by username, user email, or user ID. It’s best practice to identify these users and either delete their connections to the org or replace them with an active user.
Let’s look at where inactive users can be found and how we can send these zombies to their final resting place!
1. User Permissions
When a user is deactivated, you should clean up all of their connections to Permission Sets and Permission Set Groups. You can do this in the Setup Menu or by deleting the Permission Set Assignment junction object with the API. The Profile connection cannot be deleted, so inactive users should be reassigned to the Minimum Access profile. That way, if this user is reactivated in the future, their permissions can be properly assigned according to the new situation.
Best practice: Clean up all connections to Permission Sets and Permission Set Groups and assign inactive users to the Minimum Access profile (Please note that any reporting based on profile name will be affected).
2. User Licenses
Users are also connected to various licenses, including Org Licenses, Package Licenses, and Permission Set Licenses. When a user is deactivated, you should delete the connections to these license objects.
By the way, Package Licenses can remain assigned to inactive users. In this scenario, you can end up paying for a partner product that cannot be used. While we’re talking about wasting money on licenses, another scenario to watch out for is when an active user has the correct license without the required permissions, or the correct permissions without the associated license.
3. Data Connections
Users are often connected to other users – an example of this is Delegated Approvers and User Managers. Bad things happen when an active user reports to an inactive manager, as this can cause validation problems for the active user. Lastly, user membership in Groups, Roles, and Queues can control record visibility and access to other enterprise systems. An inactive user can be removed from the Role Hierarchy, and individual membership in Queues and Groups can be deleted.
Best practice: Delete the inactive users from all Groups, Roles, and Queues. User connections to inactive managers and approvers should be reassigned to active users.
4. Metadata Links
There are dozens of metadata assets that contain usernames. There are Running Users for Analytic Snapshots, Named Approvers for Approval Processes, Assigned Users for Escalation Rules, and Administrators for Portals – the list goes on and on. In some cases, these metadata assets will stop working when the associated user becomes inactive. The most famous example of this is when a dashboard stops working after the running user is made inactive.
Best practice: Replace inactive users with a trusted administrator in the release management process. You could also delete the metadata assets, but watch out for unintended consequences.
5. Email Addresses
If inactive usernames weren’t bad enough, in some cases the raw email address belonging to an inactive user can also be left lurking in your org. You can make the user inactive, but they still receive automated email messages! You could turn off their corporate email address, but that trick will not work for external partners and consultants. Examples of this problem include Apex Error Notifications, Auto Response Messages, Case Routing, Connected App Contacts, Escalation Actions, and Workflow Emails.
By the way, usernames and user email addresses often look identical in Salesforce metadata. Refer to the metadata API documentation to untangle actual usernames from raw email address strings.
Best practice: Replace old email addresses found in metadata assets with the current email address for a trusted administrator.
6. Team Members
Inactive Users can be assigned to Account, Case, and Opportunity Teams. In most cases this is historical information that should not be changed. These connections remain useful for reporting purposes. However, we recommend removing inactive users from Open Opportunity Teams. These team memberships should be deleted or transferred as necessary.
7. Folder Sharing
Inactive users can have access rights to Dashboard, Document, Email Template, and Report folders. Sharing Rules are an important source of access rights for Custom Objects. Inactive users should be removed from all Groups, Queues, and Roles. Manual Sharing Rules that refer to inactive users can be deleted as well. This will streamline organization wide sharing and simplify sharing recalculation.
Best practice: Clean out references to inactive users in Folders and Sharing Rules. These systems are complex enough already without a bunch of inactive users slowing them down.
8. Record Ownership
Inactive users remain the owners of Objects that they have created. In some cases, this is desirable for reporting purposes. For example, closed Opportunities should have their historical sales team left intact. In other cases, you may want to remap Object owners to a trusted administrator or active team member.
One scenario where this makes a big difference is when you need to remap inactive owners to active ones while migrating data between orgs. Inactive object owners also complicate org splits and mergers.
Best practice: Preserve object ownership where historical reporting is important, but otherwise replace inactive owners with active team members.
Summary
Hopefully this article will help you vanquish the inactive ‘zombie’ users in your org. If you would like an automated toolset that solves problems like this for you then please check out our Snapshot product, available on the AppExchange. You will sleep better at night knowing that inactive users aren’t prowling your org!
Comments: