As I have been around to a couple of different companies using CRM, some of which have been implemented before I started working with them and some I have been with from the start there are some things that can be said of the address management in CRM 2011. My general recommendation being to not use it as it is but to do some minor changes to make it work for you.
To start off, I would like to go into some detail of how the address handling is actually done in CRM.
There is, as you probably have seen, a field with the default display name “Address Name”. This can be hard for normal users to understand without instructive training. What it should be used for is to specify what the name of the address or that customer is as an internal name for that address, like “Main office in Berlin”. Due to the ambiguity of the field, I have seen different ways of putting data into it, one is repeating the company name, where the notion is that it is to be the first row of the address when mailing, in essence being the “name to which the address is going”. This field is also a requirement for some logic in CRM, in particular the different address lookups you can find for instance in the Order or Contract. For an address to show up in this lookup it has to have an “Address name”. This is also the main selection data in this lookup (by default anyway), why a descriptive name is useful, for instance “Main office in Berlin” and “Postal address”.
So, why this requirement on address name, you might wonder? Well, behind the scenes this logic is a bit more complicated. When entering an address into address1 or address2 in an account or contact, it will actually sync this to a replicated instance of the customeraddress entity in the background (created when the account/contact is created, with addressnumber 1 and 2). This is the same entity that you are looking at when looking at the “More addresses” in the contextual navigation menu within account or contact. CRM then maintains sync between the data in the account/contact and the customeraddress. These two customeraddresses are, however, filtered out from the list shown in “More addresses” but you will find them if you check the SDK or the database.
Hence there is need for some good data in the field “Address Names” so that it can be used in the lookups but it is also hard to intuitivly understand what to put into this field with the current caption.
Hence my general recommendaton for this field would be to either change its caption so that it is more instructive or have some automated logic set it by default.
An interesting fact is that the no address names field have been set by in the sample data provided by Microsoft that can be installed from within CRM. So if you want to demo the address lookups, make sure to set some fitting address names first, otherwise the address lookups will be glaringly empty. Let’s hope this changes soon.
The second field that is interesting is the drop down with the default display name of “Address Type”. It contains several values indicating which type of address this is. I have not seen any built in logic that uses this data. As there is some very significant correlation between this drop-down field and the “address name” I would recommend either linking these with logic or removing the “Address Type” field from the form.
Which fields are used for the specific address is usually country dependent. For instance the field address1_line3 and address1_region is almost never used in Sweden but is more commonly used in countries like Germany or USA. I will not go into which field are to be used for the address due to this reason. My general recommendation being to keep it as simple as possible. For multi-country implementations, try finding the lowest common denominator.
An additional interesting point is the Outlook syncronization of contacts. This syncronization will use the first address and as the address in Outlook for a contact, is syncronzed to the back-end mail server (usually Exchange) and then on to the Windows Phone (or similar inferior device). From the phone, the most usable address is the visiting address, as that is usually what you are looking for when you are checking the contact in you phone. There is also a default mapping of address1 in account to address1 in contact for contacts created from the account. Based on this, I generally recommend defining address1 as the Visiting address for both account and contact as this will harmonize best with the mobile way of using this data.
As for different ways of implementing the logic, I have seen a couple of different ways.
The first version that you will encounter is the standard way of handling addresses based on the logic of the field described above. This will in general confuse the users with the two fields with correlated information without logic to tie them together, the other is what I mentioned above, that the ambiguity of the caption “Address name” makes things confusion. The fact that the address type field also exists on both addresses, especially on address one, means that contacts created from an account will with the default mapping have different address types showing up in Outlook and in the mobile devices. And I for one, do not believe that the invoice address is all that interesting to have in the mobile device. I would not recommend using it without some customizations.
There is also a problem with using the “Address Type” field as this will mean that there is no simple way of knowing which address is the postal address, the address type always has to be checked. This really complicates things when doing integrations to other systems as well, as they usually don’t work this way. It also makes analysis based on this data more complex, and in particular makes it too complex for normal users trying to do some ad-hoc reporting with charts, advanced find and excel.
Another way of using addresses that I have seen is to change the caption of address1_line1 to be “Postal Address” and then address1_line2 to be “Visiting Address”. Some of the people I have discussed this with like it because it makes life easier for them (they don’t have to enter two addresses). This means that the other fields will be shared between the two addresses like the field “address1_city”. They also argue that for most customers these are the same. However, for group of customers, usually larger, that have different visiting and postal addresses also on a city level, this makes things problematic as it is very useful to have the City also on the visiting address, for instance when navigating to the customer with a GPS, and you don’t want to be stuck at a PO-box.
The way I like to set the address management up in CRM starts of by defining the two addresses to usually Visting address for address1 and Postal address for address2 for both account and contact.
I trim the address fields and remove the address type field.
In some cases I also create an additional script that will copy the address from address1 to address2 if the latter is empty.
I try to make sure that the address fields in Account, Contact, Customer Address, Quote, Order, Invoice, Contract and related entities are similar.
As an extra note, for the Swedish market, we, at CRM-Konsulterna, have created a small ISV-solution available on the marketplace that does this. Please read more about it here (Swedish): http://www.crmkonsulterna.se/Pages/SvenskStandardanpassning.aspx
As there are no rights or wrongs in this subject, please feel free to leave a comment. I would encourage a discussion on the subject.
MVP, CEO and owner at CRM-konsulterna AB
Interesting article on a topic for never ending discussions!
I would just like to add a note on how we solve this for a customer with high and strict requirements for address management.
On the account form, address1 is used for Postal Address (as this is still their primary way of communication) and address2 is used for Visiting Address.
The Address Types and Names of these addresses are disabled and hard coded using js, with submitMode=always, just like one of your examples.
In addition to this, we have a post create plugin triggering on Account that creates two additional addresses (3 and 4) with types Invoice Address and Delivery Address. The address fields for these are simply copied from the Postal Address on the account.
This way, the system (workflows, reports, charts etc) can always assume that the four different address types are available on each account, which is a good way of ensuring the quality of information in the system.
Thanks for the input. I agree, it is a very interesting subject.
Your solutions sounds very solid too.
Thanks for a well-written article on an interesting topic!
A related question regarding address handling:
Have you come across any company where it was necessary to setup temporary addresses with "valid from" and "valid to" dates, for instance for handling a contact with two postal addresses, where one is valid during Jun, Jul and Aug and the other one valid throughout the rest of the year?
How would you set up that kind of address handling?
@Fredrik: Interesting subject, no, I have not come across that. I would need to know more about the underlying business requirements before designing something around that. For instance, what the addresses are to be used for. Perhaps using some kind of workflow logic and "shadow" address entity to handle the different addresses might be possible. But it depends a bit more on how it is to be used.
@Fredrik: Did you find a solution we have a similar situation where clients live in Florida in the winter then move back north in the summer.
Thank yoy for your reply. I think in my organisation (CRM online 2015) we have the same issue: we use the 2 standard addresses within the "account entity". After that we have to make additional addresses (address entity) manual like an invoice address. in our situation the invoice address similar to "address 1"of the "account entity", so a copy function will be perfect. The invoice address can be used in quotes, orders, project etc. Is the copy function what your plugin does and is it available?
Barry Loekenbach Aviva Solutions
This comment has been removed by the author.