Data is big business and with the amount of data on earth growing at an extraordinary rate, good data is becoming even more valuable and can often be taken for granted.
Within Salesforce you have a lot of powerful reporting tools available to you. These are native to Salesforce e.g. Reports and Dashboards and also available to you on the AppExchange as well as other external API Integrations. These reporting tools can give you tremendously valuable insights into your customers, internal users, partners and other data you have stored. However, this is where bad data can hinder you. If you’re data is incorrect, malformed, or misleading, the insights and reports are going to be less than helpful. In other more cliche words, Garbage in = Garbage out.
So what is an example of bad data in Salesforce?
An examples I like to come back to as everyone can relate, is a little field calling Billing Country. By default Salesforce does not have any validation in Billing Country (Although saying this there is a picklist feature in Beta see this video and documentation).
In this field you could enter anything you like for any country you could enter USA, US, United States, US&A, or if you’re really confused, Alaska, Texas or Baked Beans. Billing Country is a very important field if you deal with customers or suppliers oversees as it is the definitive field to report on to find out about customer country segregation. A simple example..
You need to report on Customers per country to see where marketing efforts needs to be pushed.
A very easy thing to do in Salesforce, lets create an Account Summary Report, group on Billing country and Sum the amount of accounts in each group, to see a total of customers per country. If we have multiple names for the same country, the reporting is going to be a mess and defeats the point of storing this information which should be readily reportable. We will have separate tables for US, USA, Alaska and United States of America, maybe even a column for Baked Beans! The total of this will have to be calculated manually. We might even have some American customers that don’t have the Billing Country filled in of which there could be 100’s!
This is just one example of bad data. Other examples could include Duplicates Records, First and Last Names reversed in the wrong columns, Too many Fields that have a similar function etc.
Solutions to Bad Data
So what exactly can be done against bad data situations like the above? Luckily we have a lot of options available to automate, validate and clean data.
Most people might regard Validation Rules as the simplest form and one of the best ways to validate and protect your data from going bad. The reason for this is Validation Rules are built inside Salesforce and allow you to create simple to complex rules to make sure that data that does not meet a certain criteria is not allowed to be saved. Check out my post regarding Account Validation Rules for a bit more information.
A quick trip to the AppExchange is a great way to look at different ways to validate and clean data with proven Apps. Dupecatcher is kind of an industry standard for free Dupe Catching and alerts. Cloudingo also have a tool for cleaning bad data by looking over your Salesforce database and giving you the tools to cleanse it. Finally, a favourite of mine is Addresstools, they give you an auto populating picklist which gives you a finite amount of countries to choose from when entering a Billing Country, something definitely worth trying out.
Something very simple to try out is using picklists whenever possible. If you have a FINITE amount of entries that could be put into a field e.g. Customer, Prospect, Supplier etc for Customer Type. You should use a Picklist, its no use leaving an open text field there for open interpretation and space for spelling errors. Salesforce are currently trialling State and Billing Country fields that are available now for your organisation, you can check out the documentation.
Workflow rules are slightly different way of dealing with bad data. They don’t exactly clean or prevent data from going into Salesforce, but they can help to update fields that maybe forgotten about. An example of this could be using a Workflow Rule to update the “Type” field on Account to Customer once an Opportunity = Closed Won. This isn’t foolproof but in a lot of examples can be used to great effect.