Do you need a custom county field in CRM 2011?

Pedro Innecco posted an article on his blog recently about considerations for customising handling of addresses in Dynamics CRM. This had some great advice clearly based on real-world experience and you should go read it now, then come back here for some more titbits on this topic.

I agree with Pedro’s view that some users get unnecessarily knotted up over labels sometimes because they are creatures of habit rather than purely logical data processing machines (which is probably a good thing most of the time). But if you re-label state as province or canton for their ‘convenience’ and they want to add an Account which is in another country they can get all flustered rather than using common sense.

The choices to make can also depend on the context of the business. If you only really do business in one US state then you might feasibly want to divide up records by the next level of hierarchy for sales territories, or service visits using counties even if they are not used for postal addressing. If your business is nationwide, then it is far less likely that anything below the first level state/region/province would be necessary.

So is the built-in “stateorprovince” field the best option?

One big thing to sway in favour of using the built-in state field (even if renamed to localise it for the business location) is that when you do a mail merge, the built-in stateorprovince field is included in the list of address fields, whereas the county field is not, and nor will any custom fields you add. Asking users to remember to add the right fields every time they start a new mail merge is a bit nuts and time consuming when changing the display name and form labels achieves the same thing more easily.

What is against it is that if you do rename it you need to change the display name, and the label on every form where it appears – but as you will see below although you should change the display name, I suggest taking it off the form in many cases anyway

Using an Option Set to make life easier

If your country has only a few top-level regions then setting up a global option set in a second field can help users avoid spelling errors. This is great where there are very few “states”such as in Canada or Ireland, reasonable enough for the 16 Lände in Germany, maybe OK for 26 cantons in Switzerland but starts to become a horribly cumbersome picklist in France, US or UK.

But I said you should use the built-in stateorprovince field for state for things like mail merging, didn’t I, so how can you get the best of both worlds? Use both!

I would suggest to use an option set for data entry then copy this value into the ‘real’ field using workflow so it is there when needed for a mail merge (yes, you can copy the value from an option set into a text field in workflow, but not vice versa). Make sure you do this when the records are created and when the option set field value is changed.

I would be tempted to only display the option set on the form, and keep the built-in text field hidden from users, and similarly make only the option set searchable (see below) since that lends itself well to use in Advanced Find for doing implicit “OR” queries simply by choosing multiple values (equals “Texas” or “Kansas”, for example).

Add the same option set and same workflow to Leads, Contacts and Accounts. Of course in CRM 2011 you can use a global option set so you guarantee to get the same items in all three entities. Make sure to add mappings for the option set and the text field to copy values from Lead > Account, Lead > Contact and Account > Contact.

Using a lookup as an alternative to an option set

If you have a few too many values for a usable option set, consider creating a custom entity to hold the “state”. This approach at its simplest would use a set of records (pre-populated ideally by data import) each of which has a single text field to hold the name of the state. Again, use workflow to copy the resulting value to the built-in stateorprovince field and make sure to map the lookup between Leads, Accounts and Contacts.

The lookup approach has a few extra possibilities that can add levels of convenience for users, such as:

• You can add more than one text field to the “state” custom entity, for example to add the state abbreviation and make this available as a find field (by editing the Quick Find view). Now users can simply type the abbreviation in the lookup field, hit tab and it will resolve to the right record. This may not be perfect in all cases but it is a damn good start – eg in the US typing “MA” will result in a list to choose between Maine, Maryland or Massachusetts since they all begin with that pair of letters. Likewise for “NE”, but in both cases three letters for Mas or Neb is unambiguous, for others use the regular abbreviations.
• You could add another field on the state record for any additional information or disambiguation to help users make the intended choices, which may be according to your own set of rules rather than some “ideal” perfectly accurate reflection of reality. Maybe there is a city which sits across two states, or some degree of ambiguity whether to use more or less precision (eg should you be looking for “London Borough of…” or just lump everything together as “Greater London”? Is Bristol in Avon or South Gloucestershire, or North Somerset, or is it a separate unitary authority in its own right?). To see this, from the lookup dialog simply select the “possible” state record and click “properties” to open the record to view (you could also include the disambiguation text in the lookup view, but if it is lengthy that might not be ideal)
• Once you have a lookup, you also have a “look down”! Opening a state record would give you instant access to the Accounts (or Contacts, or Leads etc) which are in that area from the left navigation. Make sure you don’t give most users the privileges to create new state records otherwise you loose the element of control which is part of the point here. Users will need to have the rights to read and “append to” on your custom entity (as well as “append” on the Account entity, which they probably already have, hopefully). Including this in a baseline security role which you give to all users will be a good way to ensure this works.

The downside of a lookup is that it does make advanced find or other reporting more clunky compared to an option set, and to do an “OR” you have to do the long-hand method of grouping clauses and so on. It’s a trade off between functionality on the form, and in the query – which do your users interact with most?

Tidy up the loose ends

Whatever solution you use to the problem, make sure you help users further by tidying up the loose ends such as:

• fields you are not expecting people to use, such as the built-in county field should be marked as not searchable so they don’t appear confusingly in Advanced Find (edit the field under the entity in your solution or the default solution, and change “Searchable” value to “no”, you can multi-select fields and click edit to change this property for several fields at once if you want to).
• rename these unused fields as well so they are obvious to future system customisers and to users when they show up in other contexts (such as mail merge field choices, Excel export list). a suffix of "DO NOT USE" on the end ought to be obvious enough
• personally I would not like to remove built-in address fields since they are not really on the Account and Contact records but in the addresses table. Hide and rename them, but I would probably avoid actually deleting them from the schema.

What do you use for states, counties and everything else? Are options sets better than lookups for this? Start a discussion in the comments below