Lessons Learned: Hide, Don’t Delete

There are benefits to starting at level 0.

  1. There’s nowhere to go but up.
  2. No one has overblown expectations of what you can do.
  3. Learning something new is literally the best thing.
  4. No bad habits, all best practices.

This was how I started my Salesforce journey…just like everyone else.

I took over an instance that had been around a few years. I was excited and nervous. I started learning with Salesforce’s Premier Support Getting Started video and training series.

I learned all about naming conventions, org security, page layouts, Chatter, and all of the things we all know and love. I learned that duplicates were bad, too many fields was unnecessary, and that Chatter could help teams communicate cross-functionally. Can we just take a moment to appreciate how amazing Salesforce is, though, seriously?

Anyway. I was a little embarrassed. My org, the one I had just adopted and decided to raise as my own, was not house trained yet. I didn’t want people coming over, even though they already knew the org and weren’t really aware that it wasn’t in optimal condition.

I went on a little bit of a change spree. I documented my org, interviewed my users, ran some reports, and I decided to do some dusting. With a back hoe.

I took out so much stuff.

We had fields that hadn’t been used in ever. Page layouts that no one saw. Profiles whose contents had been emptied long ago. Role hierarchy?! They didn’t need no stinkin’ role hierarchy. (Just kidding. They did.)

I went in like a wrecking ball, and I started to lose track of some kind of important things. Namely my users. And data.

In my desire to makethingsbetterrightthissecond, I just started making changes. Sure, I knew that best practice was to use picklists instead of MSPs, but I missed some things along the way.

Such as hiding fields before you delete them.

As it turns out, sometimes fields are sparsely used because they’re only used on certain record types or in certain use cases. If you delete them, that data goes away.

For instance, if you have a field to track those people that need to be invited to a special client event every year, and that number is small – like only 50 people – it may seem like it’s almost never used. And technically that’s right. But it’s also sparse because it’s kind of a VIP indicator, and not everyone can be a VIP.

People were displeased when that field suddenly went missing.

I received emails and phone calls. I explained righteously that since the field had not been used, it clearly was not needed. Ah…I was incorrect.

Oops.

The next things I learned were how to restore records from the recycle bin, the location of our weekly data exports, and how to import data.

What I should have done

I’m not the first person to learn this lesson the hard way. I won’t be the last. But if I can help one person avoid it, I will consider myself successful.

Hide fields. Hide them. Remove the field from the page layout, take away Read access, whatever you have to do to hide it.

But don’t delete the field.

I know you want to clean your org. You should. It’s a good thing to do. But you have users to consider, not to mention your own time.

So when you’re digging through the muck, don’t throw everything out. Put it out of sight, out of mind. Your users will let you know if you took away something important. Trust me, they will let you know.

Since I didn’t go about it the right way, I can’t tell you what a safe timeline is, but I’d probably give it 6 months to a year. It looks excessive, even to me looking at it after I just suggested it…but really, it’s viable.

In the example I gave, there was a once-per-year conference, so giving my users a year to realize that they were missing it? Totally reasonable.

Take this small but important piece of advice and live by it. You will be glad you did.