Tell me that I'm wrong but it would appear the State and Country picklist feature makes it impossible to integrate / import Leads with state values from countries where you are indifferent to the data quality of the state value. Thus, losing information and making the marketing department mad at you.

Use Case 1 - South Africa not configured to have any States (OOB config)

Imagine CSV enter image description here

If you import this, the first row succeeds, the second row fails with FIELD_INTEGRITY_EXCEPTION:There's a problem with this state, even though it may appear correct. Please select a state from the list of valid states.: State/Province:State

Even worse, in the UI for the Lead record from row1, you can't edit/enter a State - even in text form: enter image description here

So, when marketing uploads 500 leads from an event in South Africa, and some leads completed their state/province in some data capture form, all of those Leads fail to update and you have to explain that SFDC can't accept state values for countries not configured with states.

Of course, the issue gets worse as there are no states configured OOB for UK, DE, FR, NL, ES, JP, KR and several other countries likely to be large sources of Leads. So, lead uploads with state/provinces of OXON or Normandie or Zuid-Holland fail.

So, what do you do (speaking here from a US perspective) - assuming state/country picklists is desirable for other reasons, e.g. to keep your US/Canada lead data clean)?

Option 1 : Configure states for more countries. Aside from being unbelievably tedious, you are then faced with what values to use for the integration values that you won't regret later on

Example, is the integration value for Bavaria in Germany:

  • Bavaria (English) or
  • Bayern (German) ???

and is the State code BY or DE-BY (ISO)?

Option 2: Give up on SFDC State and Country picklists and retain text-based entry of state/country with validation rules to enforce proper spelling (no picklists)? Users using SFDC UI wonder why, unlike every other system they have used, there are no picklists for this basic address stuff.

Conclusion Here's what I don't get: How does an international company use an SFDC seemingly useful feature (State and Country picklists) and still allow upload of lead data with states from countries where you don't care about the data quality of the state values? Why should I be forced to configure hundreds of states/provinces and enforce rules when the business doesn't really care.

Catch-22 If I don't configure the states, I can't receive Leads with states from countries with unconfigured states (e.g. Germany, France, ...).

If I do configure states, then Leads with states have to match my chosen integration values - else error. (e.g. must be Bayern, not Bavaria, must be Baden-Württemberg not Baden-Wurttemberg (no diacritical)

  • 2
    I have hit the same wall, making state and county picklists useless for us. Not only would it be mind numbing to implement, but there are perf issues w over 1000 values. If it was possible, just country picklists would be better option as at least there would be some benefit. I posted an idea for that a few months ago. Looks like it's only me for now. success.salesforce.com/ideaView?id=08730000000E2NLAA0
    – gorav
    May 21, 2016 at 23:58
  • yes, a) country picklists and b) state picklists for selected countries; state text entry for all other countries
    – cropredy
    May 22, 2016 at 0:45
  • agree that your proposed solution would be ideal. I didn't set my sights quite as high :)
    – gorav
    May 22, 2016 at 15:26
  • I can't believe after 20+ years of database software that international address standardization issues like this would still exist.
    – jroyce
    Nov 24, 2021 at 18:59

1 Answer 1


I'd propose a third option: a custom field and a trigger on the lead object. The custom field could be called something like "Other State" and would hold the state value as text if it was not in the standard picklist. You could then create a trigger on the lead object that would run before an insert and move the value from the standard field to the custom field if necessary.

This obviously does not allow you to store the state in the standard fields but it does prevent the data from being lost entirely and allows the lead to be created.

  • interesting...i'd have to check to see that the validation of state actually occurs during the VR phase of execution as opposed to the required fields/data format phase of validation (as the latter occurs prior to triggers)
    – cropredy
    Sep 1, 2016 at 15:16
  • This could help: developer.salesforce.com/docs/atlas.en-us.apexcode.meta/… This quote at step 2 makes me think you'll be ok: "When the request comes from other sources, such as an Apex application or a SOAP API call, Salesforce validates only the foreign keys. Prior to executing a trigger, Salesforce verifies that any custom foreign keys do not refer to the object itself." The next step is execution of before triggers.
    – vscuorzo
    Sep 1, 2016 at 16:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .