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"

"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.

Struck by Lightning: Part 1

(this is a post from Alli about a project she's been working on mostly without Michelle!)

After coming back from Dreamforce this year, it was impossible to not feel excitement over the newly released Lightning Experience. We all recognize that Lightning is the future for Salesforce, and are eager to get on board, even at this early stage when it’s specifically geared towards sales teams and their pipelines. I was asked to don my “admin” hat and roll it out to our sales team.

 
astro and i had matching halloween costumes

astro and i had matching halloween costumes

 

We've begun the process of rolling out Lightning Experience to our sales team, with a plan to be live in early Q1 -- so even though we're still in the middle of this project, I have some thoughts about what we've lightning-experienced so far.

Everything Has Changed

First, this is the first time in 10 years of working with SF that there's been something new and different enough that I've had to stop and actually learn it from scratch. Lightning isn't just an iteration/improvement on an old thing, there are some fundamental differences in how things work and what's even possible, and that means that I've had to learn it by reading and practicing, not just diving in. (Even the "new" Report Builder in Winter '11 was pretty easy to understand if you had any experience with the old Report Wizard, for example.) So, after I made it through all of the relevant Trailhead lessons, I created a new Sandbox to get into the nitty gritty of it all. Turning “on” Lightning Experience is easy, but understanding what that actually means is the challenge.

Following the Trail

Also, this is the biggest change we've ever really undertaken in our own Salesforce account that hasn't been entirely invented by our own team. We build all sort of custom objects and complex workflows or processes, and things like that, but for those projects, I'm one of our primary Salesforce Admins, so I'm always involved in the development/creation of the new thing -- it's not something external that I've had to learn and become an expert about, because I've usually invented it, so I've been the expert all along! Lightning has required a whole new approach to getting up to speed. Lucky for me, Trailhead and the community were already abuzz with tips and project plans for me to borrow from.

Reviewing Business Processes

And lastly, I realized as we began the project that it's been a while since we last evaluated the business processes in the sales team. Even before getting into LE directly, it's been interesting and valuable to talk to a sales user and learn about the day-to-day tasks (and find out some of the annoying things that we probably could have improved ages ago!). For example, the Opportunity page layout that's assigned to the Sales Team profile has never been customized specifically for them -- and as a result, nearly ¾ of the page real estate is taken up by fields that would never be filled in until the Opportunity is long-since Closed Won. Even if we weren’t going to migrate them to LE, this is something we could easily fix, but only by taking the time to have that discovery conversation.

We're still right in the middle of things -- here's the project plan Trello board as it stands today:

 
"done" is always the best column

"done" is always the best column

I'll post more updates as we move further along! Next time, I'll talk about some of the most surprising things I've discovered about Lightning Experience and how it's going to change our processes.

Why you seriously shouldn't ever just rename a user instead of creating a new one

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)

(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.

francine totally wasn't here in 2010

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 running user is inactive!

  • 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:

we miss you, lily!

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.

sell ALL the tickets!

 

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.)

Spring Cleaning: Contact record fields

We have a demo account that our sales team uses to show our prospects PatronManager. It's about five years old now and showing its age -- there's lots of weird historical data, and lots of accumulated one-off customizations that weren't ever really documented because it's not a "real" account. There have been lots of users over the years, all of whom have had System Admin privileges.

Our company and our sales team is growing, so it was time for a reset. Most of the accumulated mess hadn't been a day-to-day problem, because the old-timers on the team knew how to work around the things that were messy, but as we've hired new people, they've had to get started without the same benefit of experience.

So we decided it was time to create a brand-new account. We imported a bunch of more-realistic historical data in order to be able to do better demos of reports and dashboards, and then it was time to tackle the fields and page layouts.

And then we realized that the lessons we were learning and decisions we were making applied to other scenarios as well -- like, anyone who's inherited an older Salesforce or PatronManager account that hadn't been cleaned up in a while.

Here are the facts we were working with:

  • There were lots of custom fields that were sometimes nonsensical (like "Dog Person or Cat Person?"), often duplicative ("VIP" vs. "VIP?"), and frequently one-time use only (like "My New Field," created on the fly to show how easy it is to create a field! ...and then left there to rot on the page layout).
  • Page layouts varied wildly and without intention -- someone would occasionally pay a bit of attention to cleaning up or reorganizing the "Individual Account" layout, for example, without taking the same care with the "Household Account" layout.
  • There were custom badges of all different color schemes and styles because they'd been created at different times by different people using Da Button Factory or something similar (which is a site we love, but stylistic consistency would be nice).
  • Certain contact records looked okay because they were the ones that were used all the time -- they had all their fields populated with data that made some amount of logical sense for being a "real" person… but little attention had been paid to the vast majority of other records, so many were incomplete or obviously fake.

Peggy Olson's contact record, before.

In short, if this were a real client account, it would be impossible for people to get anything done, which made it a pretty terrible demo situation.

We needed to fix things.

Here's how we did it:

  • We designed a whole new set of badges and did a serious audit about what they all meant and how their formulas should be written. The old account had one badge field for Major Donor and a whole different badge field for Lapsed Donor -- we combined those together and added in a few more options to make a single coherent Donor Status field.
    • There were also separate badge fields for "VIP" and "Notable Patron"... we decided that was too weirdly similar so we cut the Notable Patron badge (because our users, the sales team, said they preferred to keep the VIP one).
  • We found and destroyed all the one-time use fields by running reports to see if the data was ever populated anywhere… mostly it totally wasn't, and if it was, the data was meaningless.
  • We reorganized all the active page layouts to help keep things organized and easier to understand at a glance, in a demo situation.
    • We made a new section specifically for fundraising data.
    • We're using a mini-Visualforce page to show donation history, so we moved that to its own section, without a header.
    • We added "blank spaces" to sections that needed more balance.
    • And we made sure to think through these changes, not just focusing on the fields that exist right now, but to make sure there will be logical places to put new fields that might get added in the future.
  • We checked our work both on the frequently-used records with complete data, and also on the records with less-complete data to make sure things didn't look super weird or confusing in either case.
  • All of this was done in the new, yet-unused account, so we had lots of chances to communicate with the team and show them things and get approvals.

Peggy's contact record, after

Everything looks so much cleaner and more usable now! The badges communicate the most important information about a contact, and it's easy to tell where to look to find the thing you're looking for.

We did the data evaluation work "by hand" in this case, by running reports and using our eyeballs, but we've also recommended the Field Trip app to clients who are interested in evaluating their use of fields in a more sophisticated way.

We would follow pretty much the exact process if we were working in a "real" account, with one exception: instead of doing all this work live in production, it would be done in a sandbox instead and then deployed after getting approval. (Though actually we've found that for MINOR changes to layouts, we can work directly in production -- we'll create a new Layout, and use Page Layout Assignments to assign it only to the person doing the work, and getting approvals from other stakeholders by posting screenshots to Chatter.)