Spotlight on Salesforce

Sometimes people leave your company or organization, because they got a great new job somewhere else, or it's just time to move on, for whatever reason. And sometimes that person has a LOT of history in Salesforce or PatronManager. When our (now-former) coworker Lily left the company after almost 11 years, we realized we didn't exactly have a comprehensive checklist in place for how to handle deactivating a user with that much history and so many automatic things set up… so it was time to create one.

Some of these steps are designed to keep things from breaking; others are just intended as "discovery" so you're not leaving any black holes of information scattered around. For example, if you're hiring a replacement for the person who's leaving, that new person will probably need the same (or similar) suite of reports that the old person used to get … so we should make sure to find them all.

(Before we go on: Remember, we are never ever going to reassign an old user account to a new person, right? Right?)

1. Freeze the User.
Freezing is a relatively new Salesforce Feature (Winter '14) and it's a great shortcut to locking an exiting employee out of the account before you have a chance to run through all the other steps of a checklist. A Frozen user can't log in anymore but the license isn't freed up until you get around to deactivating them. (Freezing is even more useful in a "terminated without notice" scenario but it's helpful even in a planned-for situation.)

2. Find Hidden Reports.
If the person is leaving amicably (as Lily is), it might be a good idea to ask her to go into the "My Personal Custom Reports" folder and throw away the garbage, and re-save publicly anything useful. If you forgot to do that, you used to have to live with the fact that those reports were out of reach forever -- but as of Summer 15, things are a little easier.

3. Reschedule Scheduled Reports & Dashboards.
Go to Setup | Jobs | Scheduled Jobs, and create a new view to find just the jobs "submitted by" your departing user. Then you can click through to each one, click through to the Scheduling screen, and then modify as needed to remove the User from receiving them. You'll also need to move on to the next step and change the running user if anyone else is set up to receive them.

4. Change Running User on Dashboards.
If you try to run a dashboard "as" a deactivated user, you get this:

Click Edit and then change the "View Dashboard As" setting to some other user.

5. Change Ownership of Chatter Groups.
Only the owner can delete a group and only people with crazy high-level permissions can change things about groups that they don't own… so you might as well.

Create a report that shows Chatter Groups and their owners.
Someone with Modify All Data should go to each Group the user owns and change the owner to someone else:

6. Reassign or Stop Workflow Tasks and Email Alerts.
You can see alllllll workflow tasks by going to Setup | Create | Workflow & Approvals | Tasks

Create a new list view on that page showing just the tasks that are assigned to the deactivated user. (For some reason, the "Assigned To" filter only seems to work if you enter the User's ID -- not their name.)
Anyway, find the tasks and then evaluate what's going on with the workflow they belong to -- can you stop the workflow rule entirely, or do you need to change the Assignee to someone else?

7. Check Approval Processes, Queue Ownership, Assignment Rules, and Data Export.
Does your departing user play a role in any of these kinds of business process? Lily did not have any of these things so we just checked each of them in Setup and then moved on.

8. Change Ownership of Accounts, Contacts, Opportunities/Donations?

If you're using PatronPortal (in PatronManager) or any other sort of Portal functionality (in Salesforce more generally), you should run a report to find all the Accounts and Contacts that your departing user is the Owner of, and change the Owner to someone else, using DemandTools or another data manipulation tool if necessary. (For whatever reason, Portals really don't like Portal Users to be owned by users without a Role, or by users who are inactive -- the Portal User gets an error when they try to log in if that's the case.)

9. Reassign Company Primary Contact?
On the off-chance the the person leaving was actually the person who set up Salesforce in the first place, it wouldn't hurt to check the Company Information page under Company Profile in Setup and make sure they're not listed as the Primary Contact with Salesforce.

10. Mark their CONTACT Record as "Gone"
If you have Contact records for your employees and not just users (and we'll probably write a post someday about why that's a good idea), make sure to update the departing person's Contact record as well.

11. Stay Connected!
Assuming there's no bad blood between you, you probably want to stay in touch with the person who's leaving after they move on. Remind them on their way out that if they were part of the Success Community or Power of Us HUB, and if the new company that they're moving to also uses Salesforce, they should reach out to someone to get those accounts merged when they're up and running in their new job.

We've both been working with arts organizations for more than a decade now, and one thing we've learned all too well is that an enormous amount of staff turnover happens at these organizations, as people move on to different roles at other companies. One of the greatest benefits of using a system like PatronManager or Salesforce is the fact that you're building a repository for institutional memory, a way to maintain continuity even as people with particular areas of expertise depart.

(we like to think of salesforce as your organization's own personal pensieve)

With different employees coming and going all the time, it can be tempting to just "hand over" a departing person's Salesforce user account to their replacement, just changing the name and resetting the password.

Don't do that!

Renaming a user destroys history. (Let's say Matilda was your development associate from 2010 till 2013, at which point she took another job and you had a series of temps doing data entry until Francine was hired as her replacement in 2014. Instead of deactivating Matilda's user and creating a new one for the temps, and for Francine, you just repurpose the account and give each of these people the previous one's old username.
But if "Francine" didn't start working at your company till last month, how come it looks like she had a whole email exchange with a patron in 2010?? Who actually DID have that email exchange? You'll never know.

Instead of creating a mess like this, you should ALWAYS deactivate the old user, freeing up her license and allowing you to create a new one!

We came up with a handy checklist that makes it easy to do this the right way:

Change the running user of scheduled reports and dashboards

Scheduled reports & dashboards will yell at you if the running user is deactivated, or if they're trying to send only to a user that's been deactivated -- so you might as well be proactive and fix it up right away before you start getting these errors!

The best way to do this, we've found, is to go to Setup | Monitor | Jobs | Scheduled Jobs, and create a new view like this:

Then click through to each of the items it returns and edit appropriately
Change the default workflow user if necessary
- If the person who left was set as the default workflow user, you'll need to change that before deactivating them! (It literally will not let you deactivate them unless you do this step.)

Reassign ownership of records

If your organization's sharing model is open, sometimes you can get away with leaving your deactivated User as the owner of some records (particularly if those records are old and unlikely to be changed/touched ever again) -- but if there's any chance that you'll be performing actions on those records (via workflow or Process Builder for example), it's better to change the Owner.

Freeze the User!

This is a relatively new option (Winter '14) that allows you to turn off someone's Salesforce/PatronManager access before actually deactivating their User. For example, as mentioned above, if the user is the default workflow user, you'll need to change that before deactivating them -- but you probably want the User to stop being able to log in right now. By freezing them, you can run around and make all the changes you want to make without scrambling.

AND, even if something goes down while you're not physically in the office and there's a user that needs to be frozen, you can do that from your phone! Check out the SalesforceA app for admins on the go.

We know that organizations "share" users sometimes to save money on buying individual licenses, but reeeeeallly you should try not to, as much as possible, for all the reasons we outlined in the introduction to this post. It's so much better to have users that represent actual people doing actual traceable auditable things.

What about seasonal/shared accounts, part-time use?

Here's a silly but not actually unrealistic scenario: Let's say the Laboratory Theatre has one Development Intern that works from September to May, and then leaves and it replaced by three Development Interns every summer (the busy season). Those interns work through August, and then leave and the theatre hires one new intern for the following year.

Lab Theatre SHOULD really be getting licenses for each person. But if they just can't justify it, what's the best alternative?

We'd probably deactivate and create a new user each "season" in this case -- give the school-year intern their own user with their own name, and maybe create a mutant hybrid for the summer to represent the three who are sharing the license -- but at least keep that separate from the user who left in May.

(More on this from the folks at Bigger Boat Consulting.)

Hi there

Welcome to Spotlight on Salesforce!

We created this blog with a focus on arts & culture organizations that use Salesforce to run their businesses.

Allison Klein and Michelle Paul, both Certified Salesforce Advanced Admins & App Builders, were founding members of the Product team for PatronManager, the CRM system built entirely on Salesforce that combines box office ticketing, fundraising, and marketing.

We're here to shine a spotlight on some things we've built, ideas we've had, and things we've learned.