Drop-down Country Selection via Picklist in MSCRM

This old chestnut cropped in up one of my projects recently – is an often requirement to replace the free-text MSCRM Country field with a drop-down list such that users can select a particular country and so avoid incorrect/ambiguous typing that makes reporting and analytics’s difficult. (England/UK/Britain being a good example where the same real-world value could be accidently separated in reports)

Adding a County drop-down list to the Account screen in MSCRM

Adding a County drop-down list to the Account screen in MSCRM

Changing this behaviour in MSCRM can be tricky as this is a change to the fundamental Address Handling behaviour in MSCRM – such that several places in MSCRM must be customised to support the requirement. As such I would usually try and steer clients away from this requirement due to weighting up the customisation required versus the benefits, as incorrect typing can easily be corrected as a manual process via Bulk Updates.

However this can still be a useful option for improving the User Experience for users of a CRM Solution in certain incidences, and so this post aims to describe how this drop-down Country selection can be implemented in MSCRM with reference to populating longer sets of Picklist options on multiple entities in MSCRM and how this can be achieved without re-keying the full list for each entity.

1. Create a Country Picklist and add this to the Account form

Adding a new Country Picklist into MSCRM

Adding a new Country Picklist into MSCRM

This field can then be added to the Account form alongside the existing current system field for Country.

Adding the new custom Country Picklist field to the Account form alongside the existing system field

Adding the new custom Country Picklist field to the Account form alongside the existing system field

2. Add a simple piece of onSave Javascript to copy the selected Country Picklist into the standard MSCRM Country field:

crmForm.all.address1_country.DataValue = crmForm.all.new_country.SelectedText;
crmForm.all.address1_country.ForceSubmit = true;

3. Add a second simple piece of onLoad Javascript to hide the standard MSCRM Country field:

crmForm.all.address1_country_c.style.visibility = 'hidden';
crmForm.all.address1_country_d.style.visibility = 'hidden';

4. Add the list of Country Picklist values, there is a great online tool provided by Mario Raunig’s blog on how to do this in a easier fashion than the normal method in MSCRM – particularly as we will often need to add this list of Countries for multiple entities (Lead, Account, Address etc) and that this XML Generator comes with a template for list of Countries.

XML-Generator for Picklist-values to use with Microsoft Dynamics CRM
http://marioraunig.blogspot.com/2007/03/save-time-and-energy-creating-large.html

Using this tool, we can export the Entity XML in the usual fashion and unzip to then edit the XML file manually in Visual Studio – we can then run a Find for the ‘new_country’ field that we created earlier:

Editing Account XML in Visual Studio to replace the 'new_country' options tag

Editing Account XML in Visual Studio to replace the 'new_country' options tag

We can then paste in the XML generated to populate our list of countries for the field.

Pasting the XML generated into the Account Customisation XML

Pasting the XML generated into the Account Customisation XML

Saving the XML and moving back into the ZIP file, we can import back into MSCRM to populate the list of countries into the ‘new_country’ picklist field. The entity can then be published to affect the drop-down.

NOTE: I believe MSCRM v5.0 will be incorporating the concept of System-wide Picklists where the same list can be used across multiple entities, this should limit the problem of recreating large picklists for multiple entities to keep the mappings between consistent. However in the meantime and for v4.0 solutions this process of pasting the Options list into the Entity XML is a useful technique.

5. The benefit of including the earlier Javascript to populate the standard MSCRM field for Country allows us to take advantage of any standard MSCRM Address behaviour without adding further additional Picklist fields. For example, when populating address details for an Order in MSCRM using the standard Address Lookup functionality:

System functionality looking up Bill To and Ship To Addresses for an Order in MSCRM

Looking up Bill To and Ship To Addresses for an Order in MSCRM

Lookup Address System functionality populating the Order Ship To and Bill To fields via the standard field set

Lookup Address System functionality populating the Order Ship To and Bill To fields via the standard field set

This earlier form-scripting allows us to preserve this functionality without being forced to add additional customisation to cater for the new Country Drop-down field we have added.

Word of warning for this approach however, the population of the standard County field is being done via Client-side Java Scripting and so will not be populated in the same fashion for any Accounts created via Workflow or Data Migration.

This is a simple customisation but can (with some caveats) be useful for improving the CRM User Experience.

Advertisements
This entry was posted in Customisation, JavaScript, MSCRM, Technical. Bookmark the permalink.

8 Responses to Drop-down Country Selection via Picklist in MSCRM

  1. Anne Stanton says:

    You might want to setup a Country “entity” and then use relationships to that instead of a CRM picklist. đŸ™‚

    • the idea of creating a Country entity crossed my mind. The problem is when you want to translate the country names for a multi-language implementation of Dynamics CRM…

    • Here is what I was thinking for a multi-language deployment using a Country entity:

      1. Create an entity with the following values
      a) ISO 3166-1 Alpha 2 Code [this is the primary identifier]
      b) Name (English)
      c) Nombre (Castellano)

      * The idea is to have support for Country names in both English and Spanish (Castellano)

      2. Edit the lookup for this Country entity and allow searching by Nombre (Castellano) and Name (English)

      3. Add a sample country in the list with the values
      a) ISO 3166-1 Alpha 2 Code: UK
      b) Name (English): United Kingdom
      c) Nombre (Castellano): Reino Unido

      3. Add the relationship with the Account entity and add it into the Account form.

      4. As a test, search in the new Country field for either UK, REINO UNIDO or UNITED KINGDOM, and the field should return the value UK.

      PROBLEM: How could I configure the system so it show instead of UK, the country name (Reino Unido or United Kingdom) based on the current locale loaded in CRM?

      • Think this could be tricky using a Lookup in CRM – as the new_name field of the Custom Entity is fixed to a single language and am not certain this can be adjusted to be language dependent. (which thinking on, leaves CRM with a bit of a hole for Base Data such as Products or Interest Categories in a multi-language environment)

        If using just 2 or 3 languages, the best method may be to add both fields (Nombre and English) to the Lookup view such that both are displayed when the user is selecting a Country. However this will still show the default name field on the Account/Contact screen after selection.

        Am sure this may have been a problem for other solutions where Base Data needs to be language independent – be interesting if anyone has a resolved this problem previously.

  2. Just one hint when adding Countries in a dropdown list.

    Since dynamics CRM (at least v3 and v4) only allow numeric values in for dropdowns, the idea of adding countries in a sequential integer order, such as:

    Afghanistan = 1
    Ă…land Islands = 2
    Albania = 3
    […]

    However this is a bad idea, since if a country is added or removed from the list, it might be difficult to keep track, or even result in mismatches. I strongly recommend fellow CRM users to use the ISSO 3116-1 unique numeric value for each country instead (source: http://en.wikipedia.org/wiki/ISO_3166-1). So in case a new country is added or removed, you will never have mismatch issues in the future.

    following this idea, a country list would look something like this when following the ISO 3116-1 numerical values:

    Afghanistan = 4
    Ă…land Islands = 248
    Albania = 8
    […]

    Just my two cents đŸ™‚

  3. Another issue with a drop-down list is the sorting of the country/region names in a multi-language system. I tried using the following code at an entity (e.g.: Account) onLoad event:


    var lb = crmForm.all.new_address1_countrylist
    arrTexts = new Array();

    for(i=0; i<lb.length; i++) {
    arrTexts[i] = lb.options[i].text;
    }

    arrTexts.sort();

    for(i=0; i<lb.length; i++) {
    lb.options[i].text = arrTexts[i];
    lb.options[i].value = arrTexts[i];
    }

    Problem with this code is that it messes up the list when it has countries/regions with accents. For example, the list in English would have Ă…land Islands added at the bottom of the list.

  4. I managed to create a sound solution using lookups to a Country entity that handles multilanguage solutions. You can find it at http://www.tinyurl.com/crmcountries – hope it helps!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s