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.