The Dynamics CRM Address Entity: More than Meets the Eye

I recently had a project that needed to keep track of different shipping addresses for each account entity in Microsoft Dynamics CRM.  The most logical place for it was the Addresses entity that comes in Dynamics CRM out-of-the-box (OOB). I thought: “Great! All I need to do is add a few more text fields, and then a field to link to the new Province entity that has all of the Canadian provinces”.

It was a modification like any other:

1)      Click “New Field”, and name it.

2)      Choose the Type (Look-up)

3)      Choose the Target Record Type.

Wait… there is nothing in the drop down for the Target Record?  But I need to connect to my Province entity!

I was confused, there must be something wrong!  But there wasn’t.

Limit to the Address Entity

The Address entity is limited in that one cannot link other entities to it. In other words, there cannot be any relationships created other than what there is OOB.  The Address entity is there for creation of addresses on Accounts and Contacts only.

My next thought was that I would get past this by creating my own a custom address entity (yes, just to have the Province look-up be consistent with Accounts and Contacts). But first, I needed to consider than maybe there is more to the Address entity that meets the eye.  Knowing that this project had a requirement to integrate to an ERP system, I thought that maybe the Address entity is needed in an ERP integration, and that I should research it more.

It is needed.

The Address entity is used for address selection from the Orders and Invoices entities.  The typical integration to an ERP system will transfer Orders (and addresses from orders) to the ERP system.  But there’s more.

For each Account and Contact record that is created within Microsoft Dynamics CRM, two address records are created within the Address entity.  Whenever the address information on Accounts or Contacts is updated, the address records in the Address entity are updated.  Essentially the address information that you see on Accounts and Contacts in areas such as Advanced Find, are “pointers” to the real Address record.

I decided to keep the Address entity and use a work around.  Using JavaScript (custom coding), a developer can make it appear that a look-up was being used in the same way it does without coding in Accounts and Contacts. It will appear seamless for the user, and will update the out-of-box province/state field with the right information, nonetheless.

Bottom line:

The Address entity does more than meets the eye. The creation of new entities to replace it should be the very last resort on any project.