I’ve been working with Microsoft CRM in production environments since 1.2 was released, but apart from some minor tweaks to the form I haven’t had to work with the Address entity in too much depth. Until now. I was surprised to find that there are a lot of, er, “undocumented features” that make this built-in entity behave quite differently than I expected. The SDK has a few remarks about the Address entity, but it took me a while to put all the pieces together, and I thought I’d share what I’ve found:
1. Two blank address records are created for each Account and Contact. Out of the box, CRM Accounts and Contacts have built-in fields to capture two addresses. These fields are address1_street1, address1_city, address1_stateorprovince, etc., as well as another whole set for address2 fields.
Whenever an Account or Contact is created, the CRM platform creates two blank address records related to that parent Account or Contact.
The purpose of these two blank address records is to store synchronized data that is entered in the address fields on the Account or Contact itself. The platform handles keeping these two entities in synch. If you change the values stored in the Contact’s address fields, the associated Address record is updated automatically.
2. The first two Address records that the platform creates are hidden in the “More Addresses” associated view on the Account or Contact. I guess this is because these addresses should be maintained on the Account or Contact, not in the Address entity itself. The purpose seems to be so that addresses added on the Account or Contact form are available when you do an address lookup on a quote or order. (Note that you’ll need to enter data in the “Address Name” field on the Account or Contact if you want it to show up in the Address Lookup view as well.)
3. You cannot update the Address record via workflow. You can create workflows based on the Address entity, but it’s not available to update itself. Not sure why, though…
4. You can’t modify the relationship mappings between the Account entity or the Contact entity and the Address entity. And you can’t add custom relationships to the Address entity.
5. Addresses are not available on Security Roles. You want to restrict users from editing or deleting Addresses? Can’t do it, at least not with Security Roles. Go figure…
6. There’s no built-in way to add the parent Account or Contact to the Address form. Adding the “Parent” field to the Address’s Advanced Find or Lookup views only returns a blank column as well. This seems to be a shortcoming or a bug of some sort. For all other entities with a N:1 relationship, you can add the ‘1’ part of that equation to the ‘N’ form. For example, if you create an entity called “Projects” with a N:1 relationship to Accounts, you can add the Account lookup field to the Project form. The lookup field actually consists of an array that contains a GUID, a string for the record’s name, and the object type code (OTC). In the case of Addresses, the only thing stored in the Address table is a field for the GUID. Without the name of the related object and the OTC, the interface can’t present a normal, functioning lookup field.
WORKAROUNDS:
With all of these limitations, organizations that need to manage multiple addresses for their Accounts or Contacts, and that need to perform logic against these addresses regularly, may need to do some workarounds. Among the options to consider: create a plug-in that “un-hides” the first two address records so they’re visible in the “More Addresses” associated views. Another option would be to create a custom entity with a N:1 relationship to the Account or Contact. This option has the benefit of allowing you to do the full range of mappings and workflow that you can do with just about any other entity. The downside is that if you want the address fields on the Account or Contact to be used and available for mail merges and Outlook synchs, the custom entity option will require some more create workflow solutions.