3 Top Mistakes Companies Make Implementing Salesforce

Home     /     Blog     /     3 Top Mistakes Companies Make Implementing Salesforce

As companies go down the route of purchasing and implementing Salesforce, implementing CRM best-practices along with the software is often an afterthought. Most teams skip this step and move into Opportunity Stage management, reports and dashboards and other shiny aspects of the implementation. While those elements can 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) Salesforce Setup Discipline

Salesforce cleanliness is a topic that dominates many of our Salesforce conversations as often times it’s not a consideration when implementing. Usually cleanliness is only brought up after its begun plaguing an instance and by then, it’s too late. The cost of a dirty Salesforce instance can be hefty and far exceeds that of a tool like Dupecatcher or Cloudingo.

Here are a couple common best-practices we often recommend to new or existing Salesforce instances:

Determining the criteria for each object to prevent duplicates.

Every company wants to prevent against duplicates, but when we ask what they constitute a duplicate, there often isn’t a single answer that can be provided. 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. In the case of Accounts, ‘Website’ can often 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 and couple ‘Website’ with ‘Country’ for multinational companies. If there are the parameters you set to prevent dupes, it’s important you set guidelines that all records must have these fields populated in order to be created in Salesforce. Simple validation rules will help enforce these guidelines.

Each Salesforce custom field has a ‘description’ area.

The majority of installations we get asked to work on do not leverage Description 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 many more people start to work within Salesforce, turnover occurs and you integrate with other tools.

A common example that often trips up many instances is when a custom field is created and then populated via a Workflow Rule. For instance, an MRR field on the Opportunity record that gets 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 of how, when and why that field was created. Simple example:
“Populated via Workflow Rule - “Amount to MRR” - when Amount is populated to report on MRR”.

While it may seem obvious to you, it may not be to an admin one or two years down the line.

The real cost here isn’t the tools or the time it takes you clean your instance. Rather 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) 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 some form of:

Growing within Salesforce and these platforms can be costly, but no more costly than spending countless hours dissecting how data is unintentionally being manipulated in your CRM. The simplest way to avoid this type of confusion is not to have one admin be the integration user for these platforms, but rather, create individual user profiles for large integrations and one default user for all your smaller integrations.

This way you can easily identify via the ‘last modified by’ or through history tracking which user was responsible for a given change. Determining which tool deserves its own integration user can be subjective and often times is.

Our belief is that if the tool is modifying data on a daily/weekly basis then it’s worth its own user. Whereas if the tool doesn’t modify any Salesforce records or very rarely does, it can be integrated through the generic API user. Insightsquared is an example of a tool that does not write to Salesforce.

3) Sandbox Management

Another simple habit to form as you invest further in Salesforce is proper Sandbox Management. This may not seem like an important process during the initial rollout, but can be one of those habits you start to build early on 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.

Often, organizations will start development in a partial sandbox and then push to production. While that can work in some cases for simple feature requests or for small organizations with 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 QA-ing can occur. Once pushed to production you can then move another dev feature to partial/full for further testing.

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

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

Salesforce Sandbox Best Practice.png

Implementing these habits early on may simply be seen as 'process' when starting out with Salesforce. It is true that they may indeed add hours to your work within Salesforce, but not without good cause. If implemented properly these habits can help you scale and build extremely quickly allowing you to focus on good problems, not bad ones. Like most habits, diving into solving all problems won't help you. You must identify the largest rock and start by moving that before you can tackle the others.

Good luck!

Related Articles