Deactivating an Admin User

Go through all the Users that that Admin has their email address on. It is probably Integration Users, or special Users created before the Integration User Licence was a thing.

• Decide which email is going to get any notifications for this user now. I would suggest setting up a salesforce@yourorg.com email address so that all emails go to the same place. BUT someone has to be regularly looking at this inbox.

For the User Account that handles the Backup, that unfortunately does need to be a System Admin, AND it must have a licence to ALL the apps you have installed in your org, so it can read and backup the data. It should also have the permission to view all files.

For the external services that this Admin has access to (eg it might be Zapier, or it might be an Accounting System, or a Forms tool, or Teams), ensure that the user is deactivated from those systems, and / or the password has been changed. Ensure you check that the integration is working after all these changes. Also go through and remove any users from these systems that are no longer Salesforce users.

While you are there, go through your Connected Apps usage and clean that up, find any integrations that are not using OAuth (eg using Token Authentication), and fix those up, move any full user doing an integration (except Backup) to an Integration user (and test!).

Write to any AppExchange app that requires System Administrator access to connect to their app to insist that they change their ways, and provide a help document as to how to set up their connection using principles of least privilege.

Either refresh all the sandboxes after the Admin user has been deactivated, or deactivate the user in the Sandbox. NOTE: Due to the issues you are going through when you deactivate, it is so much easier to refresh the sandboxes (and delete sandboxes not in use), than to deactivate on multiple orgs.

Please check that you have downloaded all the metadata and / or have no ongoing development or testing in each of the sandboxes. Also check if you need to export any test data specifically created in the Sandbox.

Ensure you remove the previous Admin from the Sandbox Creation Public Group so they are not activated automatically on the new Sandbox.

Now, in a perfect world all the flows would be the latest API versions, and The flow error recipient is set as "Apex Exception Email Recipients" not "User Who Last Modified the Process or Flow". Unfortunately though Prior to Summer '18, the Flow Error Emails would only go to the Admin who last saved the Flow. See here https://ideas.salesforce.com/s/idea/a0B8W00000GdbxGUAR/choose-who-to-send-flow-fault-emails-and-process-builder-error-emails-to and the Summer '18 release notes https://resources.docs.salesforce.com/214/latest/en-us/sfdc/pdf/salesforce_summer18_release_notes.pdf. This was API Version 43.

Unfortunately I still get error emails from Flows or Validation Rules I created 12 years ago, and I have not been working with the client for 4 years!

So you will need to deactivate and reactivate ALL the Flows (you have migrated Process Builders, hopefully), to ensure the new “Apex Exception Email Recipients” works.

Even after successfully deactivating the System Administrator user, issues can still arise if all dependencies were not thoroughly checked and re-assigned. Since an Admin often has sweeping control and is typically the person who sets up all system-level functions, any overlooked dependency can cause a downstream error.

Here are the most common things that can go wrong after deactivation:

1. Automation and Process Failures

Although the system won't let you deactivate a user who is the Default Workflow User or sole Email Alert Recipient, other automations can still break:

• Process Builder/Flows: If a process or flow attempts to update a record that is still owned by the inactive user, the automation may fail, even if the flow itself was created by someone else. The inactive user's records should have been re-assigned prior to deactivation to prevent this.

• Time-Dependent Workflow Actions: If the deactivated user was the original owner of a record that is still in a pending queue for a time-based workflow action, that action may fail when its scheduled time arrives.

• Apex Exception Email Recipient: If the deactivated admin was the user designated to receive Apex Exception Emails, the new System Administrator will not be notified of critical Apex code failures until this is updated in Setup → Email → Apex Exception Email.

2. Integration and API Failures

This is one of the most critical and often silent points of failure.

• Third-Party Integrations: If the deactivated admin's username and password (or security token/OAuth) were used to set up a connection with an external service (e.g., Marketing Automation tools, ERP systems, external reporting tools), that connection will break. Data synchronization will stop immediately and silently.

  • Fix: You must log into the third-party system and update the Salesforce credentials to an active "Integration User" or the new Admin's credentials.

3. Reporting and Dashboard Disruption

• Scheduled Reports: Any report that the deactivated user scheduled to run and be emailed to others will stop running and being delivered. The new admin must delete and reschedule these reports under their own name.

• Dashboards: Dashboards set to "Run as specified user" where the specified user was the deactivated admin will stop refreshing. This can lead to management receiving outdated or completely blank dashboard views.

  • Fix: The new Admin must edit the Dashboard Properties and change the "Running User" to an active user.

4. Data Ownership and Visibility Issues

• Record Updates: While the system allows an inactive user to own records, other active users may not be able to update those records if sharing rules or validation rules depend on the owner being active, or if a user with limited permissions tries to update a record owned by an inactive user who is outside of their role hierarchy.

• Sharing Rules: If the deactivated user was a member of a Public Group or Queue that is used in a Sharing Rule, their membership in that group/queue may be affected, potentially altering data visibility for others.

5. NPSP-Specific Failure

• NPSP Nightly Batch: As discussed, if the new Admin did not properly delete and re-create the NPSP scheduled jobs (like Rollups) under their own name, the nightly process will stop. This will cause critical rollup fields on Contacts and Accounts (Total Gifts, Last Gift Date, etc.) to become stale and inaccurate, impacting fundraising decisions.

Source https://help.liaisonedu.com/TargetX_Help_Center/Salesforce_Basics/FAQ/What_steps_should_I_take_when_an_Admin_leaves_my_institution%3F#:~:text=Last%20updated,when%20updating%20those%20records.%E2%80%8B