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.
10 comments:
Hi.
Thanks for addressing these issues. Just to comment on your conclusion:
If people start to design their own address entities, they also loose all built-in functionality on the "Lookup Address" button, E.g. Invoice, Order, etc. Also the built-in reports uses address1_*, address2_* fields from the views in the database.
Therefore this is *not* a recommended approach, when weighing up the things you loose.
Cheers,
Michael
You're right, Michael. I had overlooked the ramifications on the built-in reports (we don't use these much except for demos). I steer my clients away from building custom entities to replicate something that a built-in entity "should" do, and instead opt for figuring out how to make the system entity match the requirements. Thanks for the confirmation of this approach.
This is a major point relative to integrations with ERP. IN our integration with Dynamics SL we have wired up the Address 1 to Be Billing and Address 2 to be shipping, and exposed the address 2 block. Howeever from there it always gets more complex because we have to addres the issue of Shipping addresses. And in most ERP's like SL the Shipping addresses actually have an ID number that identifies them So address Name on the Address form becomes the Address id.
In several installations we have used the Contact object to actually represent the Shipping addressed as these ususally represent the end users or somehting of the like.
Either way who ever designed the Addres1 / Address 2 part in CRM was not thinking of integrations.
Good post. Thanks for confirming that I'm not crazy. I ran into this same behavior while setting up a GP/CRM integration with Scribe. I wish I had found this before spending 2 days on the phone with MBS support. I can confirm that this is the same behavior in 3.0 (it looks like your screen shots are for 4)
Thank you for this explanation and proposed workaround. A client just asked me about the limitations and how to get around it and your post summed it up nicely.
Linna
Thanks - been scratching my head for hours as to why I was getting extra address records!
Hi,
I actually wrote an article about this as well for Dynamics CRM 2011, which explains why the addresses are hidden, how to find them, and some hints on jScript and workflow customisations. You can follow up the post by clicking on the url of my name.
Hope it helps!
This helped so much - thank you!
Thanks for sharing the insight on Address entity. Saved a lot of time for us.
Just want to drop a note in here that the you can actually see all the pertinent addresses for an Account or Contact in the "More Addresses" area. This is merely an Associated View which you can modify in the Settings >> Customization >> Address >> View >> Associated View. Edit the criteria to show you all by removing the greater than 2. This will show you all but assumes really that this should align with your business needs though.
Post a Comment