Salesforce Growing Pains: 8 Common Mistakes

At Dreamforce 2013 I had the great honor of co-presenting a session titled Growing Pains: Scaling Your Salesforce Implementation. You can find the session recording on YouTube here. I spoke about the common mistakes administrators can make and the impact on user experience. This post contains some of the material I presented. I highly recommend you watch the recorded session for some great additional information on change management, governance and other considerations.

The following include screenshots. Some of these are fake. Sadly, some of these screenshots are not fake. Various information has been redacted to protected the guilty.

Common Mistake 1: System Admin Profile

It’s full of System Admins

In small organizations it’s very common to want to share all information for everyone. This makes sense! When you’re small you need everyone to know everything. You don’t have the people power to specialize.

Knowing everything and having access to everything are two different things. It can be a very tempting to simply make everyone a System Administrator or provide everyone the “View all” or “Modify All” permission. Don’t do it! As you grow this will come back to haunt you. You need to have an effective change management process where the keys to your Salesforce kingdom are safely guarded (see YouTube link above for more).

Giving everyone the System Administrator profile is often the first of many cascading mistakes causing future admin heartache. Personally, I feel bad for that one user who only has the Standard User profile.

Common Mistake 2: Too Many Public List Views For All!

So many options

This is a very common issue that arises from too many people who are able to manage public list views, often from having too many system administrators. A public list view is very beneficial. It helps builds standardization across a team and make sure users are able to easily fine key items.

Too often, list views get created for one-off situations where a user believes everyone should see it and it simply grows. My favorite is seeing users create list views named after themselves which never get removed. How many “My Open Opps” views do you need? Lock down the  permission to create a public list view to a select few individuals.

Don’t let a group view a list view if they don’t really need it on a regular basis. I once overheard a new sales person cry in frustration “All I want to know is what Opportunities I have.”  Too many list views equals too many confused users.

Common Mistake 3: Not Using the Description Field

The Description Field Is My Friend

Repeat after me: “The Description Field Is My Friend.” I’m serious. Go on. Say it out loud. I’ll wait…

The description field is the Admin’s most valuable pieces of setup real estate. It’s can only be viewed if you have access to setup. It is available on almost every item (Fields, Objects, Validation Rules, except for Page Layouts Vote Here ). Consider this field your supplemental memory and training documentation.

Your description field is a key place to put information around why you created the field. Where is it going to be displayed. Who’s going to use it. Where are they using it. Why did you just change it. It’s your spot for a mini-business case. This  is important for many reasons. It helps you as the admin remember why you did something 2 years ago – or in my case last week. It also helps when you leave the company or expand your team.

That can be a lot of information to put one spot. I like to put a short blurb in the description and then a link to a record in Salesforce (like a case) or a shared document source that has a more complete list of details. This way when you’re in a hurry you have a click link access right in Salesforce to the information you need. When you’re busy the last thing you want is a mysterious custom field.

Common Mistake 4: Not Having a Naming Convention

A field by any other name

A famous poet asked “What’s in a name?” Shakesphere’s Juliet implies Romeo’s name,  Montague, means nothing. Shakesphere may be right when it comes to matters of the heart, but he’s dead wrong with Salesforce.  Naming conventions are key for your sanity. Not only does a naming convention help you find something in the future, it will help your relationship with developers that you work with. This applies for to your fields, objects, validation rules, workflow rules, everything.

Create a document for your naming conventions. Need a special naming convention for a series of fields or objects? There’s a really good place to put that information (See Common Mistake 3).

The screenshot is a nice example. The fields may make perfect sense to the person who developed them, but imagine you’re a new admin. What are these fields? The name gives you some hints, but why so many on the same object? Are the numbers important?Maybe there is a naming convention, but where is it? This is also another great example of why “The description field is your friend.”

Common Mistake 5: Profile Proliferation

What’s 1 More Profile?

The good news is not everyone in your organization is a system administrator. The downside is you created a profile for every user in your company. Profiles are a great way to assign a set of standard permissions across groups of users. Back in the “old days” when a single user needed a special permission you had to create a different profile.

No longer! Now we have permission sets. It’s  better practice to have Profiles  control your standard permissions across a broad group of users and then use Permission Sets for the special exceptions. An example, we have a “Division A Sales” profile. That profile sets the default record type for Opportunities, access to the specific fields for that division and Read/Write on Opportunities. Suddenly we have 2 users who will be doing “Inside Sales” and need to have access to leads. Instead of of creating another profile, we can simply assign a permission set.

A great example of the power of Permission Sets can be hard on the great ButtonClick Admin podcast from Andy Ognenoff. With the power of Permission Sets he was able to have only 8 profiles for an org of over 5,000 users. It’s a great podcast on permission sets and other security information. Listen here.

Common Mistake 6: Never Cleaning Up Picklists

Too Many Values!

First, this is a completely faked error message. There is a limit to the number of picklist values? More importantly the bigger the picklist the bigger the pain for your end users. Sure you could potentially have 1,000 entries in a picklist. Can you imagine a user scrolling through a 1,000 unfiltered picklist values? I can’t.

Make sure your pick list values are useful. Make sure you have a definition for each value. Do you have multiple values that could mean the same thing? Do all your end-users know what these definitions are?

Remove values that you no longer need. It’ll be easier on you and on your end-users.

Common Mistake 7: Using Fields Instead of Related List

It’s Just One More Field…

This is one my biggest pet peeves. Creating fields is easy. It can look very pretty on the page and it can be a nice user experience. Who doesn’t want to click edit and just fill out a form. This a good thing. Not every piece of data is suitable for a custom field.

The screenshot is a perfect example. What happens when hit a fourth anniversary? Create a new record? Create a new field? What about the fifth? Sixth? In this scenario, these anniversary dates were also tied with revenue numbers, Revenue Year 1, Year 2 and Year etc.  This is a perfect example of something that should be placed in a related list.

“This isn’t user friendly Brian!” Is the cry I hear, “Our users have to create the record then create multiple items!” That’s very true. Properly designed it’ll benefit your users in the long run. What happens when you get a record that goes 5 years? They don’t need to both the admin to get a new field. They don’t have to re-create the whole record. They just hit “New” for that related list and move on.

Common Mistake 8: Not Using Your Sandbox

I Do Not Develop In Production

Repeat after me: “I do not develop in production!” Louder! This should be a mandatory sign on every Admin’s desk.

This is my biggest pet peeve. Not everyone gets a sandbox. I understand that. Go grab a free developer edition for your testing. For everyone else – you have no excuse! A sandbox is your playground.

Learning a new feature? Use your sandbox.

Wonder if a new formula will work? Use your sandbox!

Creating a new app and need to create a demo? Use your sandbox!

See an interesting AppExchange app you want to try? Use your sandbox!

Using a sandbox keeps your production org clean. Only fields you’re using are in your production org. Using a sandbox also let’s you hide your mistakes! Screwed up on your formula field or a workflow rule? Imagine what happens if your change something, made a mistake and your users see it? Users will start to doubt the data in Salesforce and your adoption will decrease. Made the mistake in your sandbox? No problem! Your users don’t see it and when you refresh and no one will know!

Wrap Up

Many of these issues occur from not having or adhering to a change management and governance policy. It can be very easy to make these mistakes with the rationale that you’ll fix them later. Don’t give in to that temptation! I’ll be the first to admit that I’ve made many of these mistakes and often with that same excuse.

We all get busy and we’ll use that same excuse over and over again. Before you know it, you’re spending more time remembering why you did something, cleaning up bad data, or simply addressing confused users.

So go watch Growing Pains: Scaling Your Salesforce Implementation it’s starts with Will Nourse talking about good governance. What mistakes have you seen? Share in the comments!