Address management

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.

This way of sharing data for different addresses with an address in CRM will also break the logic described above with the address lookups in for instance Order and Contract. The address name has to be set to “Postal Address” and there will be no way of for instance setting the delivery address of an order to the “Visiting Address”. As for the argument of it being easier, that can be solved with a couple of lines of javascript code that default the data from address1 to address2 if it is empty.

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.

Next I create a javascript that sets the “Address name” fields to “Visiting Address” and “Postal Address” and then disables and force submits the fields.

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):

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.

Gustaf Westerlund
MVP, CEO and owner at CRM-konsulterna AB

Problems with converting email to case

Problems with converting email to case

I was recently working with a customer when I noticed an interesting bug in CRM 2011, in the Outlook Client. When trying to convert an email to either a lead, case or opportunity directly from the Outlook ribbon, it does not set the “regarding” lookup field of the email that was tracked. However, if the email is first tracked, then “viewed in CRM” and then from the CRM email form converted to lead, case or opportunity, the regarding field is set correctly.

To make this a bit more clear I will describe this with a few screenshot below:

We’ll start off with opening a received email and pressing the Track button in CRM

This will then allow us to press the convert to Opportunity, Case or Lead, directly from Outlook. A very neat, and new function. It came with CRM 2011. In this example, I am selecting Case.

 This will show a smaller dialog allowing you to select case (not shown here) and also prompting you if you want to open the case or not. I selected to open the case.

After opening the case, I checked the closed activities to see if the attached email that was I just converted to a case, but as you can see below there were none. I was a bit perplexed as I was showing this new functionality to the customer as was expecting to see the email here.

I went back to the email from Outlook and opened it in CRM and found that it had not been correctly connected to the case using the lookup “Regarding” field.

So, I tried it the old way. I sent myself another email, pressed the track in CRM button, and then instead of converting it directly from Outlook, i pressed the “View in CRM” button to open it in CRM.

I then converted it to a case from the ribbon menu from the CRM Email from by pressing the “To Case” button.

I was shown a similar small dialog letting me select subject for the case and similar and then the case form was shown. It was identical to when created from Outlook, but when checking the closed activities there was one important difference;

And by opening the CRM email form from the list shows it clearly:

The regarding field has been set properly.

This is a very unfortunate bug in CRM and I do hope Microsoft solve it quickly as the feature that CRM 2011 adds in Outlook by being able to convert emails to cases, opportunities and leads directly from the email form is very good but as all of you know who work close to sales or customer service people, their time is very precious and every click counts and new features that do not deliver as expected are always annoying to the user. So, until the bug has been fixed, make sure the users open the CRM form to convert the emails.

Update: Jukka Niiranen left a very informative comment to this posting below informing us that Microsoft probably will fix this bug in UR6 planned to be released in Jan 2012.
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB

CRM 2011 IFD

Internet Facing Deployment is one of the most important features of Dynamics CRM 4 and will be so for CRM 2011 aswell. It is the enabler for real multitennancy environments and for accessing Dynamics CRM from the Internet.

As I mentioned previously, in CRM 2011 there have been some major changes to this feature as it is now based on Claims based authentication. I tried setting this up for the Beta release but the AD Federation Services 2.0 requirements were a bit over my head.

Well, Microsoft acknowledged this and have now released a video on how to set this up and they mentioned it on the CRM Team blog aswell.

I havn’t tried it yet, but videos are an excellent way of learning how to do these things since you can pause, rewind and do it one step at a time.

If you have any experience of setting up IFD for CRM 2011, please drop a comment.

Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB

Lecturer at certification preparation courses

CRM-Konsulterna and Informator, have agreed on a partnership and as part of this I will be one of their regular Dynamics CRM lecturers. Since Microsoft are changing their partnership program, with a lot more focus on certification requirements, we are kicking off with two certification preparation courses for the Application and the Customization exam. If the interest is good, we will most certainly arrange courses in Installation & Configuration and Extending Dynamics CRM as well. Later on we are also planning some Microsoft Official Dynamics CRM courses, both CRM 4.0 and CRM 2011.

So, make sure that you and you consultants are up to speed and join me for an instructive and very hands-on course that will certainly prepare you for the types of questions you will be facing in the exam.

The courses will be held at Informator in Stockholm, but if you have interest in attending a course in some other place, please let me or Informator know and we’ll see what we can do!

At the following links you can read some more about the courses:
CRM 4.0 Application

CRM 4.0 Customization

Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB