The Top 3 Mistakes Companies Make When Implementing Salesforce

This post was last updated on 12/05/23.

Overview

As companies begin their Salesforce journey, implementing CRM best-practices along with the software is often an afterthought. Most teams skip this step and move straight into opportunity stage management, reports and dashboards, or other shiny aspects of the implementation process. While those stops along the way will certainly produce a great deal of value, the key to a good Salesforce deployment is forming habits that ensure you have a clean, thorough, and well-documented instance that protects against future confusion and headaches.

The good news is, it’s never too late to start forming these habits, whether your instance is brand new or you’ve been using Salesforce for years! In fact, we’ve seen that these habits can save upwards of hundreds of hours in the long run if implemented properly. Here are three of the most impactful.

1) Establish Salesforce Setup Discipline

Salesforce cleanliness is a topic that dominates many of our Salesforce conversations with clients, as it’s frequently not an initial consideration when implementing. Unfortunately, cleanliness is typically only brought up after a Salesforce instance is plagued by uncleanliness, and by then, it’s too late. The cost of a dirty Salesforce instance can be hefty and far exceeds that of tools such as Dupecatcher or Cloudingo.

Here are a couple of best practices we recommend to new or existing Salesforce instances to support cleanliness right from the get-go:

Determine the criteria for each object in order to prevent duplicates.

Every company wants to prevent against duplicates, but when we ask them what constitutes a duplicate, they can’t provide a succinct answer. We recommend keeping it simple.

For leads & contacts, use “email” as the unique identifier. If that’s too broad, couple that with last name to ensure further precision. For accounts, “website” can usually handle the majority of records as the unique identifier, but in some cases you may need to establish further layers, such as parent/child relationships. You could couple “website” with “country” for multinational companies. If there are the parameters you set to prevent duplicates, it’s important that you establish guidelines that dictate that all records must have these fields populated in order to be created in Salesforce. Simple validation rules will help enforce these guidelines.

Give each Salesforce custom field a description.

The majority of installations we are asked to work on do not leverage descriptions when creating new fields. While it may not seem important to populate this during the initial setup, it will save countless hours down the line as more people start to work within your Salesforce instance, turnover occurs, and you integrate with other tools.

A common example known to trip up many an instance is when a custom field is created and then populated via a workflow rule, such an MRR field on the opportunity record that is populated via a workflow rule when the amount field is populated. In the description field, best practice would be to simply note the workflow responsible for populating that field, to avoid confusion around how, when, and why that field was created.

Here’s an example of what that might look like:
“Populated via Workflow Rule – ‘Amount to MRR’ – when amount is populated to report on MRR.”

While this may seem like an obvious solution to you now, it may not to an admin one or two years down the line.

The real cost here isn’t the tools or even the time it takes you clean up your instance. Instead, it’s the difficulties it creates for your sales team to properly execute on their responsibilities, and the cost associated with reps who won’t adopt a CRM because it’s difficult to use.

2) Take Advantage of Integration User Profiles

One of the biggest benefits of using Salesforce is the wide variety of apps you can integrate it with. Some of the most common are:

• Marketing automation platforms such as Marketo or Hubspot
• Messaging platforms such as Intercom or Drift
• Sales acceleration platforms such as Outreach or Salesloft

Growing within Salesforce and these platforms can be costly, but no more costly than spending countless hours dissecting how your data is being manipulated within your CRM (or any given integration). The simplest way to avoid this type of confusion is to avoid having one admin be the integration user for these platforms. Instead, create individual user profiles for your larger integrations and one default user for all your smaller integrations.

This way you can easily identify via “last modified by” or history tracking which user was responsible for a given change. Granted, determining which tools deserve their own integration user can be subjective, and often is. If you can afford it, though, we highly recommend taking advantage of user profiles within your larger integrations.

In our opinion, if a tool is modifying data on a daily/weekly basis, it’s worth assigning individual user profiles. If the tool doesn’t modify any Salesforce records or very rarely does, though, it can probably be integrated through the generic API user. Insightsquared is an example of a tool that does not write to Salesforce, and therefore probably doesn’t require multiple user profiles from within your company.

3) Manage Your Sandbox Correctly

Another simple habit to form as you invest in Salesforce is proper sandbox management. This may not seem like an important process during the initial rollout, but it should be a habit you build early on in order to save time down the road. The hidden cost here is not disorganized sandboxes —it’s the accidental process of implementing a change set to production that is not properly tested or fully thought out.

Organizations will often start development in a partial sandbox before pushing to production. While that can work in some cases, such as for simple feature requests or for small organizations with only one change, as you start to build out many different requests, you should start segregating your sandboxes so that each dev copy has its own feature build-out.

This way, individual admins can work on pushing each request, one a time, to a partial/full sandbox where final a QA evaluation can occur. Once pushed to production, you can then move another dev feature to a partial/full sandbox for further testing.

If you’re up against a particularly large project or initiative, or a lot of time has passed, it may be time to refresh the partial/full copy sandbox instance to make sure you’re always representing what the current version of the production instance looks and feels like.

See the image below for a great illustration from Salesforce explaining this process.

Conclusion

Implementing good habits early on may be seen as (perhaps unnecessarily) adding to the entire process when first starting out with Salesforce. It is true that habit-training may indeed add hours to your work within Salesforce, but it’s totally worth it! When implemented properly, good habits will help you scale and build extremely quickly, allowing you to focus on the good problems, not the bad ones.

As with building any good habit, you’ve got to start small in order to set yourself up for success. Start by moving that first obstacle before tackling the others. Little by little, you’ll make impressive progress and soon be setting your sites on the next big challenge.

Good luck!