Considerations for Deactivating Users

Situations preventing deactivation

Some situations can prevent you from deactivating a user. In these cases, you must freeze the user’s account first to prevent logins while you reassign ownership, memberships, and so on, as needed. Then you can deactivate later.

User licenses and billing

A deactivated user doesn’t count against your organization’s available user licenses. However, deactivating a user doesn’t reduce the number of licenses for which your organization is billed. To change your billing, you must change your organization’s license count.

Users in custom hierarchy fields

You can’t deactivate a user that’s selected in a custom hierarchy field even if you delete the field. To deactivate a user in a custom hierarchy field, delete and permanently erase the field first.

Process Builder

Processes can't update records that are owned by inactive users. When you deactivate a user, also transfer that user's records to an active user to avoid failed processes.

Workflow email alert recipients

You can’t deactivate a user that’s assigned as the sole recipient of a workflow email alert.

Customer Portal Administrator users

You can't deactivate a user that’s selected as a Customer Portal Administrator.

Permission set and permission set group assignments

Inactive users can still be assigned to permission sets and permission set groups. We recommend that you remove these assignments after you deactivate users.

In general, standard permission sets related to permission set licenses can’t be added to permission set groups that are assigned to inactive users. The behavior occurs because you can’t assign the related license to inactive users. However, if the inactive users were separately assigned the permission set license before they were deactivated, you’re able to add the standard permission set to the permission set group. Standard permission sets related to user licenses can also be added to permission set groups if all assigned users, both active and inactive, have the required license. To avoid this behavior, we recommend that you remove users from permission sets and permission set groups after you deactivate them.

Record access

Deactivated users lose access to any records that were manually shared directly with them, or implicitly shared with them as team members. Users higher in the role hierarchy relative to the deactivated users also lose access to those records. However, you can still transfer their data to other users and view their names on the Users page.

If a user was manually shared more than 10,000 account records, you can experience performance issues when you deactivate the user. We recommend that you first delete these manual account shares using the Bulk API before deactivating the user.

Chatter

If you deactivate users in an organization where Chatter is enabled, they’re removed from the Following and Followers lists. If you reactivate the users, the subscription information in the Following and Followers lists is restored.

If you deactivate multiple users, subscription information isn’t restored for users that follow each other. For example, user A follows user B and user B follows user A. If you deactivate users A and B, their subscriptions to each other are deleted from Following and Followers lists. If user A and user B are then reactivated, their subscriptions to each other aren’t restored.

Salesforce Files

Files owned by a deactivated user aren’t deleted. The deactivated user is the file owner until an admin reassigns the files to an active user. Files shared in a content library can be edited by other library members with author or delete permissions. Sharing rules remain active until an admin modifies them.

Created By fields

Inactive users can be listed in Created By fields even when they’re no longer active in an organization. Some system operations create records and toggle preferences, acting as an arbitrary administrator user to complete the task. This user can be active or inactive.

Records owned by deactivated users

You can create and edit accounts, opportunities, and custom object records that are owned by inactive users. For example, you can edit the Account Name field on an opportunity record that’s owned by an inactive user. This feature requires administrator setup.

It's possible to deactivate a user before reassigning the records that the user owns. However, if the user owns more than 10,000 records for a given object, we recommend that you transfer ownership of these records before deactivating the user to avoid performance issues when the system updates access.

Enterprise Territory Management

Deactivated users are no longer assigned to territories and are removed from the territories they were assigned to.

Account and Opportunity Teams

Deactivated users are removed from the default opportunity and account teams of other users. The deactivated users’ default opportunity and account teams aren’t removed.

When a user on an account team or opportunity team who has Read/Write access (Account Access, Contact Access, Opportunity Access, and Case Access) is deactivated and then reactivated, access defaults to Read Only.

Opportunity teams

If you deactivate users in an org where opportunity splits are enabled, they aren’t removed from any opportunity teams where they’re assigned a split percentage. To remove a user from an opportunity team, first reassign the split percentage.

Delegated external user administrators

When a delegated external user admin deactivates a portal user, the admin can’t remove the portal user from teams that user is a member of.

Lightning dashboards

When you deactivate a user who owns a dashboard or is the running user of a dashboard, the dashboard doesn’t return expected results. To prevent the issue change the dashboard owner.

CRM Analytics

When you deactivate a user who scheduled a dataflow, the dataflow schedule is deleted and the dataflow is unscheduled.

#salesforce #saaspointindia