State and country picklists can save your users valuable time. Perhaps more importantly, they minimize variations that would junk up the data and make it too painful to process. By standardizing the options for countries and states/provinces/territories you can prevent the variation that comes with text fields and ensure cleaner data in your system, making it more manageable and easier to get insight from.  

Consider the United States for example. In a text field, users can list the country as:

  • US

  • U.S.

  • USA

  • U.S.A.

  • United States

  • The United States

And that doesn’t take into account differences in capitalization that naturally occur in a text field.

When each country and state in your system is entered as text, the potential variations can be overwhelming. You’ll have data in your system that’s expensive to store and impossible to harness for reporting and other purposes. It’s a costly issue to face.  

When it comes to implementing these as picklists, the standard state and country picklists in Salesforce might not be the right solution for your business. Let’s talk through why and when each option may be more beneficial. 

Use Cases for Standard State and Country Picklists

The most compelling reason to use standard Salesforce state and country picklists is that your organization ships products nationally or internationally. 

State and country picklists are based on ISO-3166 standard values, so it’s safe to use worldwide. That’s important for shipping physical products to their destinations. 

If you’re not shipping products and your motivation is that Sales and Marketing want to clean up the data around locations, that’s not necessarily a compelling use case in our experience. 


  • It’s a time-intensive feature to convert to unless your Salesforce org is quite small. 

  • It requires a lot of maintenance around any integrated systems that use that data. The more integrations you have, the more complex that maintenance becomes.

  • It doesn’t work with custom objects. If your organization relies on any custom objects for address data, state and country picklists can’t be used with them.

  • In general, the larger your organization and the larger your Salesforce org, the more intensive the process. 

Here’s something that really hits this point home: Italy is the 72nd largest country in the world. But it has over 100 subdivisional codes. On the other hand, Australia is the sixth-largest country in the world and has just eight codes. (For even more perspective, Australia is about 26 times bigger than Italy.) 

Whatever expectations you may have about implementation, you’ll want to check the assumptions they’re built on to make sure there won’t be any nasty surprises.

Another case in point, the United States has 63 different state and territory codes in the ISO-3166 standard values that Salesforce uses. We know the country includes more than just the 50 states (we see you, Puerto Rico and Guam), but 63 is still higher than we expected. 

How to Save Time and Money With State and Country Picklists

As with everything Salesforce, it’s always smart to consider the possible solutions, weigh them against your needs, and determine which will provide you the maximum value for the minimum investment. 

If your organization isn’t reliant on shipping physical products but still needs the ability to process location data, then there’s another option that may save time and money for your organization. 

For clients who don’t need the exact ISO-3166 standard values in order to ship their products, we suggest implementing a global picklist for countries that clients can maintain themselves. For the countries where they care about states and/or territories, we create a dependent picklist for those. 

For example, if someone selects United States from the global picklist, the dependent picklist activates and requires the user to select a State. In our experience, this captures the overwhelming majority of the data. An “other” option can capture the few entries that might not be represented in the picklist options. If you do the majority of your business in a few specific locations, then what value does it provide to represent every location equally? That would also bog down your Salesforce org with data that isn’t valuable to your business. 

For organizations that don’t need accurate shipping information and do the majority of their business in certain geographic areas, an “other” option in the picklist can streamline your data, saving time, money, and people power. It will provide an answer for the limited responses you may receive outside those major geographic areas of your ideal and typical customer. Again, it’s all about tailoring the Salesforce solution to your needs.

Your Organization is a great candidate for this solution if:

  1. You don’t ship products out. 

  2. You need normalized country names for data processing, but the states and territories within those countries don’t need to be ISO normalized. 

  3. Your Salesforce org has a lot of custom objects and a lot of existing integrations that you would have to rework in order to implement standard state and country picklists. 

  4. You do the majority of your business in a few locations and don’t need an expansive list of locations in order to have insight about your typical or ideal customer. 

At Cloud Giants, we like to think of Salesforce features as a starting point for determining what functionality will be the right solution for your organization’s needs. In our experience, the standard feature or out of the box functionality isn’t necessarily the right solution for your business — it’s all about getting the most value for your specific need.

Features like the standard state and country picklists can be incredibly useful, but knowing when it’s worth investing in that solution versus another that’s more tailored to your needs is a surefire way to get great ROI and make your Salesforce org work for you.