Enabling State & Country as Picklists in Salesforce – Part 2

April 15, 2013 Matt Lamb

by Matt Lamb (@SFDCMatt)

In Part 1 of this post, we outlined the process of enabling the new State and Country as Picklists feature in your org, and went over the first step of enabling and configuring the feature. This post will address the data mapping and conversion process.

Salesforce has provided an interface that allows you to select one or more values and map them to their newly standardized values. The interface shows a consolidated list of all values that show up in any of the standard State or Country fields, so you won’t have to map each object individually. First you’ll map the Countries, then the States.

As you start to work through this process, you’ll no doubt notice some data that you can’t easily map. This data likely falls into four categories, ordered from easiest to hardest to resolve:

 1. Misspelled or Variant Data

How many users have been hand-typing these values into your system over how many years? As a result, you’re likely going to see plenty of misspellings, as well as different ways of writing the same values. Things like “UNITED KINGDOM”, “UK”, “U.K.”, “Great Britain”, etc. These should all be straightforward enough to map.

  • The algorithm that matches existing data to the standardized values is case sensitive, so UNITED KINGDOM will show up in your list of things to be mapped, even though United Kingdom is the standardized picklist value.
  • You can vote on the IdeaExchange (https://success.salesforce.com/ideaView?id=08730000000kdPlAAI) if you’d like to have that matching be case insensitive.

2. ISO Codes

If you have ISO code values stored in your State and Country picklists, you’ve got a leg up to some degree. Although you’ll probably have a challenge knowing what all those values are. Quick, what’s the 2-digit code for South Africa? Of course it’s NZ. I spent quite a bit of time on this page (http://www.iso.org/iso/country_codes/iso_3166_code_lists/country_names_and_code_elements.htm) when mapping ISO codes.

3. Junk or Misspelled Data

Someone accidentally entered a zip code or an email address into the State or Country field, or goofed and typed in Chian instead of China. If the value is relatively unique, like an email address, it’s easiest to use the Global Search feature to locate the offending record and find the correct State/Country data. In the event that the value is more common, like a zip code, use the Reporting tool to look for the particular field that contains the value you’re looking for.

4. States entered as Countries

This could step from user error, but can also be due to geopolitical changes over time, especially if you are converting an older data set. Items such as Puerto Rico could appear in your older data set as a Country, though the standardized values provided in Spring ’13 have Puerto Rico as a State tied to the Country of United States.

  • Currently there is no way to map a value in a Country field into the corresponding State field in the interface, so you should consider adjusting this data outside of the conversion interface, using on the numerous data loading clients like Apex Data Loader or Jitterbit.
  • You can also vote on the IdeaExchange (https://success.salesforce.com/ideaView?id=08730000000kdQyAAI) for Salesforce to develop a more elegant solution to this problem

The State mapping process uses the same basic interface, and functions in the same manner.

The biggest thing to note about the state conversion process is that since the Spring ’13 release only contains states for the United States and Canada. This means that if you have critical state values stored currently for another country, such as Brazil, you will not be able to map those values to a standardized picklist value, thus the values will not be maintained.

All values must be mapped in order to activate the feature. At any point during your data conversion process, if you’d like to update the conversion interface to account for actions such as editing records manually to correct some junk data, you can always run the scans again, which will update the list of values to be mapped in the conversion interface.

Once you have all your values mapped, you’re half way toward enabling this feature! Catch Part 3 of this post to understand the ins and outs of what happens when you turn the picklists on, so you can better understand what you need to change about your existing customizations.

Previous Article
Workday Integrations Made Easy Part 1: No Complex SQLs
Workday Integrations Made Easy Part 1: No Complex SQLs

By Vikas Wadhwani   In a typical implementation, there can be as many as 60-70 integrations to and from oth...

Next Article
Enabling State & Country as Picklists in Salesforce – Part 1
Enabling State & Country as Picklists in Salesforce – Part 1

by Matt Lamb (@SFDCMatt) If you’ve ever put address data into Salesforce, you’ve no doubt noticed that you’...