The scenario described in our previous blog post on analyzing data during a migration tells a very realistic story of a user just trying to get her job done while challenged with capturing required information for management. There was no malice or ill-conceived attempt to sabotage the company’s data, but nevertheless the data that resulted from that scenario had very little value. It requires a little care and effort to extract out what is valuable and to leave behind all that is not.

So let’s discuss some ways to identify and manage some of the more common data entry issues I find while performing data migration analysis.

Bypassing Required Fields

Humans by nature are adaptive and creative. We see a problem and easily find ways to work around it. Thus, we should keep this in mind when determining which fields we want to mark as required and its impact to usability.

If a user does not have access to required information they will simply put some random value in or worse be forced to keep track of the information outside of the system on paper, in Excel, or even their own database. So we should strive to be selective about the information that we mark as required.

For required fields to be valuable users need to understand their value.

To illustrate, imagine the following scenario:

There are a couple of $100 bills sitting on a table and for every bill you take and put in your pocket you get a mild shock. In that position it’s easy to imagine that you would most likely suffer through a few mild shocks to fill your pockets with a few $100 dollars.

Now imagine that same scenario, but this time every time you take a $100 bill you received the same shock but do not get to keep the money and instead you have to hand the money over to someone else. How many times do you think you would take that $100 bill and hand it off? I am guessing maybe once before you decide there is nothing in it for you.

This scenario is my crazy of way of saying that you need to be able to communicate the value of any required fields in your system in such a way that your users find it valuable as well. If you are unable to do so then it is less likely that your users will care about entering accurate information into those fields.

You will see evidence of users bypassing required fields when analyzing the data of your current system in the form of random data or gibberish having been entered. If there is a large percentage of invalid data it can be a good indication that this went unnoticed for some time and that the data might not have been as critical as you once thought. It could also indicate that the information you require was not available at the time the record was being created, as was the case with Jane, and it might require that you adjust your process accordingly.

In situations where information is required and you want to avoid invalid data from being entered Salesforce does provide a mechanism for validating user input in the form of Validation Rules. These rules can go a long way in improving your data quality and avoiding invalid data. However, keep in mind that it should not prevent users from entering valid data so being very clear about the rules and format of valid information is critical.

Incomplete Records

It is in our nature to look at the world from our own unique perspective. So it is very common to start a design session with a few hundred fields on the table to be implemented. They key of course is refining this list of fields into something that is manageable for your users but still provides the information you need to analyze your business.

One great way to gain a perspective on what information is truly critical is to take a look at the data of your current system. Now it is likely that your current system never really fit your needs or your business has dramatically changed over the years, but I am willing to bet there are still some lessons to be learned from this data.

For instance, there are likely many fields on an Account or Contact that you have configured that are not being used. Some common issues I have seen are additional address and phone number fields. In the case of CRM we tend to want to collect every possible way to reach our customers. This can lead to as many as four different phone number fields and just as many address fields. It is likely these same fields exist in your current system for the same reasons. By analyzing your current data we can identify if this information is actually being collected.

Another possible factor is that certain types of Accounts or Contacts only use some of the defined fields. For instance, maybe you maintain vendor contacts and customer contacts. Many fields are earmarked for vendor contacts and others for customers. Salesforce provides Record Types for this type of scenario so that your users do not have to selectively ignore fields depending on the type of contact. Instead, Salesforce can present a page layout that only contains the fields that pertains to a vendor contact or customer contact. You can also independently validate or mark fields as required based on the type of contact.

Incorrect Formatting or Data Entered in the Wrong Field

It is very common to find data that has been incorrectly entered or formatted when migrating data from one system to another. Often times the data appears to be complete and we are well on our way to loading the data before we realize there is a problem.

In reviewing these errors often what I find is that users have either used a field for something different than its intended purpose or have added additional information. Here are some common reasons this may occur:

• The field label may not clearly indicate the type of data that is expected. Maybe the system/process expects a number to be entered and the user enters text
• The user might not understand when to use full-text vs. codes. Such as when working with products
• The user misspells key values as they are entered. These misspellings are made worse when auto-complete for form fields are enabled and the user consistently uses the same misspelled value

To overcome these data quality issues we typically perform some cleanup routines to the data being migrated. This cleanup comes from analyzing the errors and data and looking for some patterns that we can use to extract invalid data and remove or replace it with valid information.

These issues do not go away in Salesforce but there are ways to guard against such issues in order to maintain your data quality. Here a few tips for maintain data quality:

• Make sure to use descriptive field labels and help text to avoid confusion with users
• Where possible use pick-list fields to provide users with a list of values to choose from rather than free-form text fields
• Where possible make sure to use the pre-defined data type fields such as phone, email, URL, number, etc.
• Use Validation Rules to validate the data format. For instance, if your codes always starts with 2 letters followed by 3 numbers a validation rule can be implemented to make sure that the data follows this format

Conclusion

A single-button-click migration tool would be great. On the surface a solution like that would save time and money when migrating to the Salesforce platform. The reality however is that you end up just fully replicating all of your data issues from your previous system over to Salesforce.com.

The existence of data by itself isn’t valuable. Data has value when it is used (i.e. business value). By taking the time to evaluate the data you have collected over the years you can use that information to improve your processes, user experience, productivity, and data quality.

Author credit: This is two-part guest blog post by John De Santiago of Iterative Logic and podcast co-host of Good Day, Sir!