If you are a sfdc admin trying to find out what to do when your user leaves your company or gets fired, this blog would help you to take concrete steps and make the right decision.
Decision on disabling the leaving user or assigning the leaving user to an existing user.
There is always a decision which has to be done on whether to close the current user id and not give to anybody or assign the user id who leaves to another user. The best practice is to never assign the existing user id who leaves to anybody and always create a new user id to a new user who joins the company.
|option||Disable userid who leaves and create new user for new people who join||Assign leaving userid to an existing user.|
|Pros||1. You can have an audit trail of all activities done by the old user who left.
2. Minimal time spent on fixing data.
3. This should be the policy for sales and marketing teams who leave the company.
|1.This can work for users who never logged in to your org or adoption is low. This can work for temporary part time users or users who have read only permissions on the org.|
|Cons||1. If the same person joins the company after some time, there will be a possibility of duplicate users in your org. This will show up only on records which would seem like there were 2 users who modified the data in the same name. But this can be mitigated by updating the old records to the new userid after they join.||1.All audit trail of the old user will be lost and will result in confusion for admins and users on old records changed by the leaving user.
2. If the old user who left the company joins again, there would be a significant time spent on fixing the records back to the leaving user.
1. Make the user inactive.
2. Check for a mobile device and click ‘Erase Data’.
a. “If the person has a mobile device, the deactivated status will be detected when the mobile client next attempts to run an update and an “Erase Data” command will automatically be sent to the user’s device (deleting all device local Salesforce data).” from SF documentation.
3. Make the user inactive if not already inactive.
If you cannot make the use inactive due to any record conflicts, click the ‘Freeze” button. This will prevent them from logging in while we figure out the conflicts.
c. If the user has been Frozen…
Check approval processes.
Handle the data owned by the leaving user.
a. Check the “Used Data Space” Section on the old user
b. If there are accounts (or other objects) listed, go to (left hand navigation column):
Data Management > Mass Transfer Records
c. Choose “Transfer Accounts” (or any other object to be transferred)
d. Transfer closed opportunities on Account transfers.
e.Do NOT transfer cases on Account transfers.
f.Use a Case view (or some other tool) to transfer cases.
g. Select users where the data is transferred Transferred From and Transferred To. Make sure these users are validated when you enter them. If the from is not validated, it will select all records!
h. Click the “Find” button. Then the transfer button if the owner alias looks right.
i. If there are still contacts owned by the user that did not get transferred with the accounts, use DemandTools (or other tool) to change ownership of contacts if there are too many to do manually.
j. Closed tasks are hard to find and transfer, so don’t spend time on them, those who need to see them should still see them on cases, etc.
k. There is no easy way to transfer solutions other than custom data migration.
Handle permissions for the leaving user
a. Change Role to “Unassigned” so that the leaving user does not have any view permissions on existing data.
b. Create a profile with minimal permissions which can serve as a place holder for users who leave. Change the leaving user profile to this place holder profile so that you can easily delete any unwanted profiles..
c. Remove any permission sets and public groups from the user.
a. Check scheduled jobs to see if any inactive users are running jobs.
b. Check default user assignments for workflow & sites.
c. Check if there are any email templates owned by the user in use.
d. Make sure user is not the “Default Lead Creator” for Web Leads.
e. Make sure user is not the “Default Case Owner” or “Automated Case User” for Cases.
f. Check if the user is the only member of a queue or being sent queue email notification.
g. Check if the user is the Google Apps Admin Contact. (Admins only)
Here is the key takeaway for you on what to do when a user leaves.
- If the leaving user has given you sufficient time for you to act, then you can do the following steps in a sequence.
- Transfer data from the leaving user records to an existing user.
- Check the other things to check and make sure you have an user covered for it.
- handle permissions for the leaving user.
- Disable the user.
- If you have to act in a hurry because the leaving user was fired or caused a security breach, follow the following steps.
- Disable the user first
- Handle permissions for the leaving user so that the leaving user can do minimal damage.
- Check the other things to check for leaving user section.
- Transfer data from the leaving user to an existing user.
Please feel free to email me at firstname.lastname@example.org for further questions or if you want a checklist on the activities to perform for the leaving user.