Salesforce IdeaExchange

Customization Comments | Customization Ideas | Force.com Platform Comments | Force.com Platform Ideas

14730

State and Country should be pick lists

We have many people around the world that don't keep typing in the correct c ountry and state name. How can we get these to be pick lists.

« Previous 1 2 Next »

Teixeira 10/12/06	Do you know how many different ways one can write United States of America or United Kingdom? Then try to do a report for these two countries at the same time trying to think of all the possibilities.
MatM 10/12/06	This would be extremely useful for me, as we could then define United Kingdom, Ireland, etc etc.
Mimma 10/13/06	It would be also useful if Country and state picklist were dependent. For example, when you select USA in the country field all States are displayed in state field and when you select Italy all italian provinces are displayed and so on.
5WheelSteve 10/13/06	This would be a very useful feature and easily acheivable I suspect as set of global tables. But why stop at Countries Provinces & States....Could we not add cities as well? Can we not take this a step further and have registered administrators make submissions for additions to these tables?
ErikM 10/15/06	I'd just love to have dependent country and state picklists, but please be aware that global companies may face problems with duplicate items, especially if they use state codes. This is because you'll find dozens of state codes that are the same in more than one country (compare Italy and the United States and you'll find more than half a dozen matches). While you can of course reuse the same state code for multiple countries, you've got to be careful if you decide to go back to full names at some later time, because then you suddenly get Arizona, California, Conneticut, Georgia, Maine and Oregon in the United States and in Italy. Best way to handle this would be to have two-column picklists, where you could decide if you wanted the code or the full name. Actually, I'll submit such an idea right away.
5WheelSteve 10/19/06	If we all get to use standardized picklist, could we not have a global company setting within Locale Settings which determines how we format out data, either abbreviations or full names....
thusker 10/19/06	This would be VERY helpful for us . . . we have even gone so far as to consider adding custom fields to try and capture this, but would be much better to have this functionality where it belongs.
vschott@xrite.com 10/19/06	We actually created custom fields to manage the lack of this functionality. Unfortunately, it rendered the contact us button useless. In addition, it was a maintenance nightmare. We ended up moving all the data back to the default fields and deleting the custom fields. I agree, it would be great to have country populate state but we manage a global, multilingual database so I would prefer SF tie the Country picklist to the phone field and format based on which country is selected. I used to have this functionality in ACT! (of all things...) and yet, I don't have this in SF. In creating a picklist for Country, it would also enable the translation. This would be a tremenous help in the data quality of Germany/Deutchland/DE, etc. I'm crossing my fingers. Hopefully more people think like us Anyway, my one dream come true with this product would be country and phone field. In having country a picklist it would then be translated.
flescor 10/25/06	Go all the way and make country and state dependent picklists autopopulated with ISO lists. Then the users only have the city, address and postal code lines to get wrong :>)
AMartin 10/25/06	I like the idea of Country and State/Province Picklists, but as long as users have the ability to import Accounts/Contacts from Outlook or other sources, Picklists will only go so far in standardizing how the data is formatted.
AFroggatt 10/25/06	This with a series of editable and dependant picklists Country/region/state) would go a long way to keeping data accurate.
RDN_LHR 11/23/06	A very MAJOR competitor to Salesforce.com has a BEAUTIFUL!!!!!! way of handling this. There are fewer than 200 countries in the world, and they've managed to do the research on every country's address format. You pick the country out of the picklist and it gives you the proper fields and format to use. Not being in the USA, I find the entire system much too skewed to American styles in every area of the system. Even though the address box is sort of free form and all that, no matter what you put in there, it wants to try to format it as: Address City State postal code Country There are so many variants to that, that to non US users, the area is just plain ugly.
The_Fox 11/29/06	Hello, I have developed an scontrol that replace any country field in any objects by a picklist and you can make it required avaliable upon request : c dot humbert at free dot fr
emmadunstone 12/01/06	I agree. We have had to create a custom picklist for each: Leads, Contacts and Accounts. As a global organization we need to allocate, report, segment and analyze based on country (and then region). This has proved very difficult for us; although the custom picklist is a pain at least it is an improvement than trying to get all the derivatives of 'UK/United Kingdom/England' etc in a report. A SFDC core picklist field could also be maintained in different languages with ease.
WCC 12/01/06	Great idea. This would resolve some serious data integrity issues. What about the thought of entering the postal code and having it auto-populate the city, state/province, country?
agluewvrs 12/01/06	To address the multiple country/matches issue... it would be great if SFDC would allow an admin with rights, to select country packages that will enable the address fields to automatically alter themselves to fit the country picked on the country picklist. The address packages could be managed by SFDC internally (they could outsource it probably) and then let admins pick whatever they need. Maybe SFDC could come up with populate country packages for regions such as APAC, EMEA, U.S., North America etc... would be sweet... data validation... gotta love it.
Aliza 12/11/06	WCC: Here in the US there are postal codes (ZIP-5) that service more than one small town, and the official databases sometimes have errors in them. (And how do you handle it when post codes change out from under a location?) I'm not saying that it isn't a good idea, just that it wouldn't be a 100% solution, and people would need a way to override errors. (But then, of course, you'd get stubborn people overwriting good data with bad data...) I think the best way to handle non-unique abbreviations would be to carry both formats along, so that someone who doesn't know that the postal abbreviation for Queensland, Australia is QLD would still be able to search their database for "all accounts in Queensland".
Aliza 12/14/06	While we're at it, data validation for phone numbers would be great. Even just having a visible reminder to enter country codes separately from the rest of the number would be a start.
thegogz 12/21/06	Hi I don't agree here. I'm a salesforce.com support rep and I can see huge problems if these fields were made to be picklists the maintanance would be huge. There are hundreds of countries in the world and there are also hundreds of states/provinces/counties (I'm based in Ireland so we dont have states we only have counties). The fields in salesforce are left as text fields to make it a decentric as possible meaning that the application applies to users no matter where they are. Realistically the problems are solved by using Validation rules in the upcoming Winter 07 release. Using validation rules its possible to get users to enter the data exactly the way the administrator wants it to be and as validation rules are enforced through the API and import it also forces users to do this during their import and using Data Loader etc.
eyewellse 12/27/06	A salesforce feature already exists to solve problems of inconsistent format and values for state and country. Instead of salesforce.com dictating what all possible desired formats and values are for your country, there is a data cleansing tool called Mass Update Addresses that will set all values to the standard ones you (the admin) select. See the help on "Mass Update Addresses" (available in all versions of salesforce.com).
LisaQ 01/13/07	An complication of this problem is that it is only possible to have 150 items on a custom picklist and there are more countried than that, so it is not even possible to create a custom picklist with all the countries.
Rup 02/12/07	All this stuff has been standardized by ISO and other postal services : ISO country codes, country-states/regions lists, address formats. This is used in many other apps, and anyone in Europ who develops any app handling addresses will use the ISO country code list : a terrible mistake made by salesforce.com up to now, which shows how badly it needs better I18N (internationalization) and L10N (localization).
TMCBA 02/22/07	A way to currently minimize the issue of inconsistent entries of state and country codes/names is to use the field validation rules. Although it does not prevent someone from inputting an incorrect code, it can help in making sure users are using a 2 character code instead of typing in the country name.
jhbenter 02/22/07	I agree this is a big problem for any multinational company using Salesforce that has multiple data sources and users with different languages. 1) The list of possible countries must be maintained inside Salesforce - only isocode should be stored in the Country field. 2) Salesforce must display this country value as per selected language in Salesforce. E.g. if I have English selected it will show DE as Germany, if I have German as language Salesforce will show Deutschland in French it would be Allemagne. 3) In all reports I can use the isocode as selector. C'mon there are not more than 200 countries world-wide it should not be an issue. And this is no thing for customizations - this is a feature Salesforce should have, especially for companies that work with multiple languages.
natek 03/07/07	Dependant picklists would be nice. For now we're going to use validation rules.
teaberries 04/18/07	I like validation rules much better than the idea of picklists. Picklists would be too cumbersome. If most of your business is in a few specific countries, you can edit your validation rule based on those provided for the US and Canada. As our business is 99.99% in the US and Canada, I've merged the US and Canada validation rules for State and Province as a requirement for all Billing and Shipping addresses and requiring two-letter codes (which I've specified per the validation rule already in SFDC). It's working great! I highly recommend tweaking those existing rule formats if you're able to do so for your own geography.
Heros 04/19/07	There is an application on the Appexchange that is similar to this request. App Name: Address Advantage 1.1 App Link: http://www.salesforce.com/appexchange/detail_overview.jsp?id=a03300000033joFAAQ
Speedy911 04/25/07	Needed big time. We almost run into this question for every implementation we do.
Hurricane 04/30/07	This is a no-brainer, and blows my mind that Country and State/Province fields have not been automated to be picklists already. Come on SF, this is basic stuff - and is a major deterrant to our ability to quickly pull reports by geography.
JLumb 05/08/07	Postcode Anywhere's App on the AppExchange solves all of these problems: Type in a zip or zip+4 and you are presented with a list of streets within the zip, click on the street and the rest of the address is populated. It also does the same for around 25 other countries worldwide. It also takes address structures into account, for example in Germany property names are behind street names in the address and Hungary addresses are completely upside down! http://www.salesforce.com/appexchange/detail_overview.jsp?NavCode__c=&id=a033...
flescor 05/14/07	It does seem that there should a basic geography table built into the app that is referenced by the Accounts, Contacts, Leads etc. objects. This can presumably be cheaply sourced from one of the address-validation vendors...
EGallegos 06/22/07	I would like to have dependent country and state picklists. So for US you would only see US based states etc. This would help in reducing the noise of multiple state codes not relevant for US or non US users.
AndreasBernhard 07/03/07	That is absolutly crucial to provide proper data quality. It should be ideally a code, which is depending on the users language displayed in the user's language
jhbenter 07/20/07	Is someone from SFDC reading this thread ?
Coccodrillo 10/08/07	Merged Idea originally posted 10/12/06 Country field (Billing/Shipping) as a picklist instead of a text field Hi, if users type in the country as a text string the error rate is much higher if you create reports. Misspelling or dfferent names for a country (e.g. UK, United Kingdom, Great Britain, England...) make it difficult to run reports. So is it possible to provide only a picklist where the users have to choose the right country ? For users in different countries this picklist could be customized with the translation workbench for all available languages. Regards, Christoph
sfinamsterdam 10/08/07	Merged Comment originally posted 10/14/06 This is a very valid point as the regular text country field cannot be removed from the edit page layout (or if it can please let me know).
sandrags 10/08/07	Merged Comment originally posted 10/14/06 yes, very useful. When we set up custom country fields, we generally use a picklist, and sf should make this feature available on its standard fields
canderson 10/08/07	Merged Comment originally posted 10/16/06 This would be great - right now to run reports on accounts/opps in a specific country, it takes some creativity to figure out all the possible ways our users have input the country name - especially UK vs. United Kingdom vs. Untd Kgdm, etc.
The_Fox 10/08/07	Merged Comment originally posted 10/26/06 Hello, I have made a s-controls that replace by default billing country, mailing country and lead country (so on Account/Contact/Lead) edit page the text box by a picklist that can be made required and this is extensible to all objects with address fields,(error is managed with the same look as salesforce.com) It could be extended to manage langage if you want (for the moment it is English only). For it to run you have to make it an inline s-controls either via a non documented feature (see salesforce heretic blog to see how) or wait for winter'07 release allowing inline s-control Available on request and as-is at chumbert at odyssey-group dot com Working with Firefox 1.5.X to 2.X and IE 6 IE7
teaberries 10/08/07	Merged Comment originally posted 04/18/07 This comment is almost identical to "State and Country should be pick lists." Vote there if you would like to promote the idea so that you don't split the vote. :-)
Heros 10/08/07	Merged Comment originally posted 04/19/07 There is an application on the Appexchange that is similar to this request. App Name: Address Advantage 1.1 App Link: http://www.salesforce.com/appexchange/detail_overview.jsp?id=a03300000033joFAAQ
Guaraldo 10/08/07	Merged Idea originally posted 11/01/06 Country Selection
DylanGray 10/08/07	Merged Comment originally posted 01/30/07 Please provide standard list of all countries globally and make an option on the address fields.
neoMagic 10/08/07	Merged Comment originally posted 07/25/07 In order to guarantee valid data entry, this feature is a must for all fields of the data type 'Address'.
jeepee 10/08/07	Merged Idea originally posted 06/07/07 Standard country/countries picklist for address details SalesForce should provide a standardized country/countries picklist for the address details of leads, prospects, accounts and contacts. The ISO 3166-1 country codes from http://www.iso.org/iso/en/prods-services/iso3166ma/index.html would be a great start. Reason: currently the country fields are free text fields and we find that everybody enters the country differently. This makes it very difficult to get accurate reports on e.g. - number of account by country - number of products sold/in use by country - number of cases by country For example, in our system we now have - US, USA, United States - Germany, Deutschland - UK, United Kingdom, GB, Great Brittain, England, Scottland
m62Admin 10/08/07	Merged Comment originally posted 06/07/07 This would be great, as long as it is the full ISO country name and not the codes, because the postal systems don't recognise the codes.
fjw 10/08/07	Merged Comment originally posted 06/11/07 This is something which has been having an adverse impact on our data quality. It is needed desparately. The next step would be to do the same for state/province codes for those countries which have standardized codes. A configuration option to use automatic validation on the address fields would give flexibility in case there actually is someone who doesn't need this.
AlexCRMmanager 10/08/07	Merged Comment originally posted 06/11/07 This should be an OPTION for Salesforce.com users, but perhaps the default option.
eric_falsken 10/08/07	Merged Comment originally posted 06/11/07 Would be nice to go one step further and to localize the entire address depending on country. I've had to type some addresses where I had no idea what the city or state was (in China for example, or have you ever seen the addresses in Tokyo?) At least display a hint as to what the region's postal addressing format should look like in a label.
mkeller 10/08/07	Merged Comment originally posted 06/18/07 It would be great to be able to utilize for custom objects also.
WrogWrog 10/08/07	Merged Comment originally posted 06/19/07 Exactly right regarding the postal codes. Those are defined by the United Nations not ISO. See http://www.unece.org/trans/conventn/Distsigns.pdf
kbaker 10/08/07	Merged Comment originally posted 06/20/07 If this is anything in the works, then it HAS to be enhanced to apply City, State, County with the ZIP code driving it for USA. WHAT A TIME SAVER to just enter the ZIP...
Christoph_Amann 10/08/07	Merged Comment originally posted 06/22/07 Another great thing would be to translate all the countries into all the available languages in Salesforce.com.I think this should be possible in the translation workbench. The ability to fit country names in the translation workbench to company-wide rules (Great Britain/ united Kingdom or Netherlands/Holland) would things make much easier.
jeepee 10/08/07	Merged Comment originally posted 07/02/07 Since everybody seems to look this request and is adding additional request I want to add another one too. What about an interface with http://www.addressdoctor.com or http://www.qas.com/ for instant address lookup, validation and cleaning.
glowitz 10/08/07	Merged Comment originally posted 07/09/07 With regard to the Jun 19 posting, the link provided is for transportation (on cars, etc.) within countries, not postal codes. All international postal requirements are based on 2-letter abbreviations (lust like states have 2-letter abbreviations. The ISO list noted initially is the best place to go. Repeated here: http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list...< also agree with other posts that better integrated address checking would be useful. However, it's often best to do this on the server-side as data is being entered into the system. Salesforce could do this as part of the form entry process for a small fee for each address checked and corrected into proper format.
sfinamsterdam 10/08/07	Merged Idea originally posted 08/06/07 Picklist for Country I coule not find this one in the list... Currently the country field is free text. So "America", "(the)US", "(The) USA", "U.S.", "U.S.A." etc all mean "United States". Same for Holland/Netherlands/Nederland and England/UK/United Kigdom etc. A picklist makes multinational selection a lot easier for reporting/creating views for mail merge etc... We can do this as a custom field but getting this flagged as a standard field (and therefore included in standard functionality such as keep-in-touch) would be a great benefit for multi-country users.
TomaszOczapowski 10/08/07	Merged Comment originally posted 08/08/07 No ideal but try using validation rules and restrict entry to a specific country names. Your users will quickly learn the right spelling which will improve your data quality and allow for reporting/grouping.
fjw 10/08/07	Merged Comment originally posted 08/09/07 As a global company, we use different record types (40+ per object) for our different businesses. Some of them only operate in one country while others are in multiple countries. This makes it impossible to create a validation rule that covers all of the combinations due to the current limitation on the size of a validation rule. The easiest way to handle this would be to have the country field be a picklist with the ISO country codes. We could then define the subsets via record types. I would take this a step further and ask for the state/province codes to be built in as well since those should be relatively stable. If any partners read this thread - a great AppExchange offering would postal code validation/cleanup for a given country & province.
datatrim 10/17/07	DatTrim - You Data Laundry on the AppExchange automatically normalizes the entered Country and/or State value into a standard (English). It even included post code validation for a wide range of countries world-wide. We are currently exploring the Apex options to see if this feature can be made available without the Webservice for the Data Laundry.
RichGottesman 10/23/07	I think Salesforce should resolve this problem internally. Why should hundreds of administrators have to keep (dependent) picklists current. It's not like countries are being added to the world all that frequently, or am I mistaken? 1. Make the country field a dropdown. 2. Make the State field a dependent dropdown on country. 3. We can handle cities and streets. If Salesforce is worried about trying to resolve this globally and might not be able to do this, then I suggest a feature to enable dropdowns vs. freeform as it is today. Also, this doesn't have to be solved in one pass. I would bet if Salesforce handled the USA and US states first, it would satisfy 80% of the people asking for this. Then, after use, Salesforce can add other countries or regions next (e.g. Europe). Problem is that Salesforce probably wants to deliver a perfect solution or do nothing. The problem with doing nothing is we're all left with mishmashed codes and abbreviations that make reporting impossible. My users actually asked for this before I thought about it! Get on it, Salesforce. Spend about 4-hours with a couple developers and I bet you'll come up with a plan to satisfy most folks with a few lines of code.
RichGottesman 10/23/07	Salesforce automatically concatenates address components into a single address field. And I agree it's US-centric. Why can't each record have an "address type" dropdown that allows us to pick (from a picklist of administrator-defined" settings) a predefined method of concatenation for addresses? That would help make Salesforce more global and less US-centric.
jap 11/02/07	This should merge with and adopt the votes of the similar, but slightly more expanisve idea http://ideas.salesforce.com/article/show/91544< can we make this happen?
jap 11/09/07	Merged Idea originally posted 10/17/07 The Cursèd Country Field! When, oh when, oh when will the SFDC standard country field be provided as a pre-populated picklist of all the world's countries? The values would be simply as defined by the UN, and maintained by SFDC centrally? Surely this is easier and cleaner than the numerous workarounds/fudges that seem to be deployed across the planet?!? Hey, it would then come as standard for the translation workbench too. Everyone would win! You know it makes sense!
montblanc2000 11/09/07	Merged Comment originally posted 10/24/07 While I agree with the usefulness of picklists, I don't see this being a practical application. Who is to say that the UN list of countries is useful to all Salesforce users? What do you do with non-UN members? Even if the UN provides a list of all sovereign states including non-members, how do you deal with (semi-)autonomous territories (e.g. Greenland, Gibraltar, Bermuda, Hong Kong, etc.)? What if some users want those territories to count as separate countries but others don't? This is something that should be left to the individual user to decide (and perhaps customize on their own).
marylou 11/09/07	Merged Comment originally posted 10/25/07 At least provide a basic list that we could customize - add in or take out as required. Even the opportunity to create a custom picklist for this field would be good (I can't figure out a way to do it anyway!).
jap 11/09/07	Merged Comment originally posted 10/25/07 Thanks for the feedback. I think we have both extremes of the argument here, which is great. The fact that the adress fields generally, and the country field in particular can't be customised from standard is probably the bigger issue. At the moment if you wan't it pick-list style, then you have to dispense with the SFDC standard address fields and build and maintain your own custom address fields. A little unnecessary I feel. There's surely should be a way to be allowed to dimension/format these fields at the outset of setting up your SFDC instance?
SteveBower 11/09/07	Merged Comment originally posted 10/28/07 Good idea, and, while we're at it, let's do it for US States as well, and perhaps cities within states, etc. Not to mention Territories, Cantons, Provinces, etc. There are many places where this would be helpful. Montblanc, if the predefined picklists don't work for your application, just don't use them. You'll be in the same position you are now.
hugeflirt 11/09/07	Merged Comment originally posted 10/28/07 If most websites in the world can figure out how to include a list of countries - then I am sure that SF can figure it out. They don't create new countries very often and if anyone wants to use a country name that doesn't exist then too bad. Data quality is affected by the lack of defined input, I haven't used a CRM product that doesn't have this defined before.
mrg 11/09/07	Merged Comment originally posted 10/29/07 Some picklists may be dynamic, in the sense that not all instances are known at the start. Why not provide for a growing picklist? Let the new customer or contact provide for the new value whenever the option "Others" or "New" is selected. If the spelling or nomenclature is not widely acceptable, then someone is bound to bring it to your attention. Additionally, an admin module can be provided to make additions directly to the picklist, or even replace items that are inappropriate.
mdevans@tribune.com 11/09/07	Merged Comment originally posted 10/29/07 I don't think this idea is necessary, especially with validation rules. Validation rules allow you to limit what goes into the field while at the same time still use the stand address fields. We have a validation rule that requires a three character country code for all accounts. Every user has a list of countries codes (ISO Codes) and the list is stored in the documents tab. It is very easy to standardize the country for your business that way without a picklist or any general standards that SFDC would set for us. (I have done the same for US states and Canada Provinces).
jap 11/09/07	Merged Comment originally posted 10/30/07 I think this final point falls down when you start considering Web-to-Lead or Case-to-Lead capture, enquirers are unlikely to know the ISO codes. I think this approach also falls down a little in terms of translation workbench requirements too. A picklist with instantaneous, translated, absolute values is always going to be preferable to the marketer - otherwise you're going to have to go through an unnecessary cross-referencing stage to get data out for direct marketing purposes.
jeepee 11/09/07	Merged Comment originally posted 11/01/07 This is a duplicate Idea with http://ideas.salesforce.com/article/show/23195 on which has a promotion count of 8240. Maybe these 2 can be merged into a single idea to get a higher count? By the way, the I don't think the UN list is good. You should use the ISO (International Organization for Standardization) 3166-1 country codes from http://www.iso.org/iso/en/prods-services/iso3166ma/index.html would be a great start. The ISO also provides a news letter that is sent out as soon as there are changes to the list, so SF could easilly maintain it.
jap 11/09/07	Merged Comment originally posted 11/02/07 jeepee - well spotted, I'm new to this, how do we merge and get the combined issue up the charts?
Kingsley 11/09/07	Merged!
nob 11/21/07	Like many here I would also like to see major improvements regarding addresses and would vote customizable picklist, (prepopulated by Salesforce and/or based on existing country set). It seems that another weakness of the current implementation has not been described in this context: The state/province address subfield will only be displayed for users with according locales, like English (US). In global operating organizations address data may be entered anywhere in the world, but e.g. with a german locale it is not possible. So the bottom line is to make the state/province field (visibility and content) dependend on the actual country and on nothing else. Hope that Salesforce has taken this on the agenda for next release, it is highly awaited.
petesav Jan 9	Couldn't agree more!! Bring on country and state picklists!! We have looked at every conceivable way of getting around this and none are remotely workable.
JohnB Jan 21	Sometime I'm surprised how "simple and logical" helps are not integrated in SFC. Please do it!
datatrim@datatrim.com Feb 1	Not to mention changing the size of the "State" field: How do you fit: "Mecklenburg-Vorpommern" into 20 char. Not eveyone using salesforce is based in the US, and therefor ideally only need 2 chars for the state (or the list of US stats to be pre-populated).
ryan_hallman Feb 11	Or at least give admins the option to change the type on the state field from text to picklist.
nzsh Feb 18	This 'idea' was originally created in 2006; do you think Salesforce are working on it? Country must be made a pick list, and for us in the UK (dependent on Org I agree)we should have the flexibility to remove elements from the address such as State/Post Code. We have had to create a new picklist for Country so we can standardise the values otherwise we'd have GB, UK, England etc
JoolsBax Feb 20	I think Country should absolutely be made a pick list. However, do we Anglicise every country name (eg use Germany instead of Deutschland, Italy instead of Italia, etc), or do we use the real spellings of Country names in the Country's language? Regarding whether SF are reading the thread... there is a comment posted in 2006 from a SF employee in Ireland, who states that the field is purposefully made free text and can be controlled using validation rules . . .
SFAdmin Feb 21	I added a validation rule to the state field so we would have consistency in how a state abbreviation was entered. If it is not entered the way it is listed in the validation rule, they receive an error message. This may not be as good as a picklist but at least our state abbreviations are correct/consistent.
dave_rogers Mar 4	I'm a DBA and create many PHP reports that pull from our databases. It drives me nuts and flat out blows my mind that our sales staff are so terrible at spelling country names. "Viet Nam" is a good example...including 5 different ways to reference "United States". They're almost creative in their ignorance (meanwhile Google is a CLICK away!). A drop down of the country is the least you can do. My goal is to pull sales order records into my own database (that I can control and integrate with MS SharePoint) so I'd have to manually fix their errors unless there was a picklist dictating what they have to put in. I don't care about the region/state nearly as much as I care about the country...it seems standard to include such a thing I think.
erikavl Mar 5	Dave, just for the record: in Vietnam, Vietnam is Viet Nam ;-)
mrm_admin Mar 10	Whether countries and cities should be dependent, I think we all agree that countries should be a drop down list. I don't know why Salesforce haven't done this yet. It should be pretty straight forward. Alternatively, they could let us, administrators, control the address fields, because now you cannot change the setup of these at all. Then we could make a dropdownlist for countries only if we wanted it, without angering the other Salesforce clients that do not want to have a country drop down list. We really need it, so that our addresses are standardised; otherwise it is almost impossible to report accurately on all the people from one country.
sfwizard24 Mar 25	I agree with mrm_admin. Let us control all address fields and create a picklist for the country field (what a lot of admins already made by creating a new custom field for country)
donnalee Mar 27	This would be so helpful to have. Common standard picklists like 50 states, Canadian provinces, countries, etc. Why would this be very difficult to offer. It's only a list.
donnalee Mar 27	For anyone who is interested I looked for and finally found a list of the 50 state abbreviations in one column which can be copied and pasted into a picklist. I apologize in advance for the obvious length of this. AL AK AZ AR CA CO CT DE DC FL GA HI ID IL IN IA KS KY LA ME MD MA MI MN MS MO MT NE NV NH NJ NM NY NC ND OH OK OR PA RI SC SD TN TX UT VT VA WA WV WI WY
jvolkov Apr 8	This can be done simply using a new custom picklist field. So why hasn't Salesforce implemented this yet?
kimc Apr 14	Data is one of a companies biggest assets and accurate, consistant address details of a lead and/or account is extremely important. By introducing picklists you are sure to be able to locate all Leads/Accounts in United Kingdon rather than having to search on: UK, GB England etc..
srinivasan_babu Apr 15	Hi, I am using Billing Country as a Picklist field and also Shipping Country as another custom picklist field, When the value of Shipping Country is not provided it as update with Billing Country value. i have tried for a workflow but cannot compare with all values at the same time need to give specific value,value above or value below. Can any one help me how to do this? Thanks in Advance, Srinivasan
ThadKill Apr 15	NO NO NO...........not a pick list! Use autofill. See my idea "Auto Fill of City State from Postal Code"
CDIC Apr 16	In our ERP system, we type in a zip/postal code and that code is tied to city, state and country codes. Imagine that, one entry fills in 4 fields :-)
ThadKill Apr 17	I can only deam!
ThadKill Apr 17	I can only dream!
CH1SAKO May 22	I thought the most voted ideas are going to be implemented... I guess that was a dream...! TO SALESFORCE: PLEASE JUST DO IT!!! Is'nt almost two years of begging enough?!
exact1 May 27	State, City, & County should be populated from the USPS guidelines and require the user to only enter the 5 digit zip code. All other fields could be populated from that point or the user could be prompted in case of multiple city names serving 1 zip. Data consistency would be greatly improved. How many contact records sit on Salesforce.com servers that are inaccurate? We had this on our prior CRM and it worked great!
Stefan Jun 10	When prospective CRM customers ask me about my views of Salesforce as a potential CRM, this lack of any country validation is my main critism. This is an appalling omission. This idea is now up to 13540 votes. Why aren't Salesforce listening?????
spambuster Jul 2	We tried to implement state & country validation rules, but gave up on country names since the validation rules only allow up to a certain amount of characters, and including the entire list of every country in the world was too long. We wanted people to include the full name of the country, not any code, so that it would be intuitive for our users. In the end we settled with validation just for the "weird" countries, that have multiple spellings, like United States, which can be written USA, U.S.A., etc. But of course it's not 100%. And worse than that, now that we are doing validation for state & country, we can no longer use the "quick create lead" from the Outlook plug in, since the state & country fields are not included! So improving our data cherence actually eliminated an unrelated but quite useful functionality. I am all for this suggestion being implemented. Truthfully, even if Salesforce were to decide to do it in a different way than we wanted (say, by using codes instead of full country names) I believe it would still be better than what we have at the moment. So.... what are you waiting for?!
jason_thurgood Jul 23	Why not make the system intuitive enough that simply entering the postal or regional codes would auto-populate the state and country information? Of coarse that only works if you know the postal code...but it would save time having to enter the data your self. Other CRMs have this functionality...

track comments for this idea

« Previous 1 2 Next »

Please log in to post a comment

last 100 promotions:

anndavis
maksim
johnalmeida
ssando
paddyslacker12122007
marc.st-pierre03132008
ann_geerts
cliodhnae
sommerjo
anngeertsat4c
smiles007
wgeis
chainaw
victoryjennifer
amarwah
jmansford09092008
salesforce42com
vanhaaren06202008
lnorris
dbhak
thecrmninja
ibarrie
daves127
egrim
pffa
swog
jennyef
ulrikek
sandeep_banga09202008
mattiasnordin
stephaniedorman
elly_bockley
olivia_lai
mike23
carlito
orkanindublin09252008
stephencartercpass
david_gildar
csidesinternap
chuck_goss
knichols
kati_suvanto
BCShazaam
spicemac09
nyicff
gmacelwee06032008
Captain_Spammer
siemensplm
hyperic
collinde
marmaduke
natecrgl
gmt
EmilyLiggett
needsomechange
noname7
yorimpi
drewalexander
marlowe
Axeda007
mohan_srinivasan
pacific_gps_info
taubium
tom4
tevans
nanahg
kent_manning
david_manelski
jason_stames
AlainaJ
pnash
dsmatana
snelly
jbivona08132008
aaamel
ecstowe
sftrifecta
samuel_williams
zabby_fazel
billbutton
philipp_rackwitz
mserviss
SMHayden75
claudeg
dwebb
seanyj
arno
jason_thurgood
placeur
keith@citect
eyal_wiz
lesslinger
daddia
analystgirl
miss_v
initsysadmin
andrewcoveney
DoyleAtTSG
msthilaire
asomma11

recently demoted by:

4/3/2007_15:38
johnwa
xroad
EricS
ThadKill
stuart_bernstein
veman1542
jgentes
ted3423141234
hatim_salih
littlefrantz

Resources

Successforce.com

State and Country should be pick lists - Salesforce IdeaExchange

Salesforce IdeaExchange

State and Country should be pick lists

Search Community

Categories

1-800-NO-SOFTWARE | Privacy Statement | Security Statement