Checklist: When a Contact is marked as "deceased"

Here's a discussion question that came up in our internal company Chatter today:

"How do clients tend to handle the marking of a deceased patron in a household when things like the Account Name, Salutations, Address Names, etc need to get updated. Workflow off the checkbox?"

We started thinking about this, and decided that a hybrid approach is the best. There are a few things that should happen automatically right away if a Contact is marked as "deceased" -- like checking "Do Not Mail" box, and changing their Email Status to "Opt-out' -- but for other things like Account Name and Salutation changes at the household level, it's probably a better idea for a human to do the work, to make sure it's right and that it's handled sensitively.

Here's a terrible example that one of our coworkers shared about what can happen if you're not handling this well:

"My friend James' Mother passed away last year, and this was the letter he received in the mail. Not only is the letter wrong, but it's causing all sorts of confusion and he'll have to call them and get it all straightened out."

"dear james, we're sorry you're dead"

But, okay, does that mean you need to train your entire staff on how to make the correct changes to fields on a record when you're checking the "deceased" box? Maybe not -- it could be that the person finding out about the deceased-ness and marking the record isn't necessarily a person who needs to be super-trained on a whole cascading list of other things to do.

Instead, let's create a workflow that does those things we mentioned above, but that also creates a task or series of tasks for particular staff members to take care of the name fields, and perhaps send a condolence card, depending on the relationship to the deceased person.

Overall, the takeaway here is: When you're thinking about new workflows for your organization, consider the difference between automatic changes that can happen in the background versus things where you want an actual human to use their brain… but don't overlook the benefit of a reminder task for the latter! Create a list of the things that should happen, assign it to the right person, and you'll be in the clear.

Checklist: What to do when someone leaves

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.

we miss you, lily!

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

we miss you, eric!

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:

theater!

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.

we miss you, piper!

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.