Deactivating a Salesforce.com System Administrator w/o Breaking the System

In any Salesforce.com system, the System Administrator is not only responsible for actively maintaining, updating, and modifying system functionality, but there are also a variety of settings for which a System Administrator is the default user.   There are probably few things as disruptive to a system than de-activating a System Administrator User without first modifying a variety of settings in a Salesforce.com instance.

Scenario: The main System Administrator for an organization’s Salesforce.com has to be fired rather suddenly, and the Management Team doesn’t want anything to break, but wants access and permissions for that user to be shut off immediately.

Solution: In the immediate term, the first step is to change the current System Administrator’s User Record’s email address to another System Administrator in the system .  Second, request that the outgoing System Administrator User find the “Email Change” acceptance email in their inbox, and click accept.  Finally, go to the User’s record with the new email address and click ‘Reset Password’.  This is a temporary solution to prevent data loss or intentional sabotage, as well as make sure that nothing critical breaks.

In the short- to medium-term, there are a variety of settings to consider updating:

Salesforce.com Support

• It may be necessary to submit a Case specifying a new Security Contact for the system.  The Security Contact is the user who will be contacted in case there is a security breach, and should be updated it is currently set to the outgoing System Administrator.

Customize

• Leads | Web-to-Lead | Default lead Creator
• Cases | Support Settings | Default Case Owner
• Cases | Support Settings | Automated Case User
• Customer Portal Settings | Settings | [Portal Name] | Administrator

Create

• Workflow | Settings | Default Workflow User

Administration Setup

• Company Profile | Company Information | Primary Contact
• Data Management | Analytics Snapshots | [Analytic Snapshot Name] | Running User
• Monitoring | Scheduled Jobs (if the old System Admininstrator is the user for any Scheduled Jobs, the scheduled job must be deleted, and then re-scheduled by a different System Administrator)
• Monitoring | Apex Jobs (If the old System Administrator is the user for any currently-running Batch Apex jobs, they must complete before de-activating the User)

Analytics

• If any Dashboards or Automated Reports have the user set as the Running User, they will need to be updated to another Active User (not necessarily a System Administrator). If this is not done they will cease to work until an Active User is set as the Running User.

Gotcha

• A User can’t be deactivated if they’re assigned as the sole recipient of a workflow email alert.
• A User can’t be deactivated if they’re the User assigned to a Task.
• A User can’t be deactivated if they are the selected User in a custom hierarchy field, even if the field is deleted. The field must be deleted and permanently erased first.

Photo Credits:  extremekites.com