Have been working with a few clients recently where the topic of managing Addresses has cropped up – particularly when a Client is working with larger Organisations and engaging across a number of Offices which can make managing the various Addresses in MSCRM difficult across different Accounts and Contacts. This is a familiar problem working with MSCRM over the years of CRM v3 and CRM v4, and so the following post outlines some approaches that can be used to managing Address Governance using the MSCRM Platform.
Customers Addresses, Accounts and Contacts
Addresses are a key element of the Contact Management aspect of any CRM Solution providing some of the most useful and frequently entered data – however without proper rules or governance about how multiple Offices or Addresses are entered into the solution, addresses can often end up as duplicate or problem data.
By default MSCRM has a free-form system for recording addresses between Accounts and Contacts that does not seek to enforce any business logic or data management rules for a MSCRM deployment – this can be summarised by the following ERD:
This establishes a model 2 Customer Address records are automatically created to serve as ‘Address 1’ and ‘Address 2’ for each Account or Contact, and then also allows users to add any number of additional addresses via the MSCRM More Addresses area.
However this model does not allow a single address to be linked to multiple Accounts or Contacts. This can often pose a problem for associating groups of contacts to a particular address within an organisation, as often a client business will need the requirement to see the list of contacts that work for an Account divided by which office or brand each Contact works at.
Dynamics CRM provides a limited resolution to this problem by Mapping an Account’s primary address to each Contact working within the Account, and then allowing a user to modify the address fields for each Contact individually.
This set of fields is then mapped down following the format of any Mappings configured in MSCRM – any Contact created directly from an Account in CRM will automatically have the fields copied down as per the mapping definition. However this has the limitation (in line with all MSCRM Mappings) of not coping down the mapped fields whenever a Contact is created and then subsequently associated with an Account.
This approach is useful for day to day contact management but can encounter problems when an Account moves Office Addresses (as the MSCRM Mappings are at the point of creation and so are not synchronised in the event of subsequent changes) and for grouping Contacts by different addresses for branches or offices within the Account.
This blog post aims to outline three approachs for helping to manage addresses in MSCRM.
Use Bulk Update to ensure Contact Addresses are up to date
This approach aims to side-step the use of Additional Addresses in MSCRM by storing a single ‘Head Office’ address as Address 1 in each Account and then storing any other office addresses by each Contact. This gives a view of Contacts at different Addresses by the Account via customising the Contact’s Associated View to show each Contact’s address within the Account:
From here, users of the solution can select groups of Contacts at a time to peform a bulk update for Office Address changes:
This is a simple no-code approach to handling office addresses, however this does rely on users of the system keeping groups of contacts updated with the most recent Address.
From a Data Management perspective, this leads to training the user community to enforce addresses are organised in a uniform fashion:
Single Account per Organisation Office or Branch
This approach can work for Users by operating on the principle that each Account record represents a single Office Address or Branch within an Organisation – such that multiple linked Account records can be used to represent an Organisation with multiple distributed offices.
Contacts can then be added to the Account which represents the office that he or she works out of.
Previously when working with CRM v3, this approach would not be usable as the format of multiple Account records would prevent a single view of history and activities from the top-level Organisation. However CRM v4 provides an Activity Roll-up to see the Activities for an Account and also the Activities for any Accounts down the hierarchy.
However this concept of a Rollup does not exist for listing Contacts, so this approach cannot provide a method for viewing all the Contacts in an Organisation, requiring (barring the development of a simple SRS Report) the user to drill down into the Branch/Account record involved to instead the list of Contacts for that office.
Additional Development to associate Contacts to Addresses
A possible third approach is to add custom development to MSCRM as a method of enforcing data management to separate out the different concepts of an Account, Contact and Address.
This is a familiar path when working with MSCRM given the massive potential for extendibility of the platform – however this should always be weighted up for the benefits against the development and support costs involved.
MSCRM automatically creates a Address Number (addressnumber) for each Customer Address added to an Account – such that the automatic Address Line 1 is held in the address1_* fields in CRM, and Address Line 2 is held in the address2_* fields, with Address Lines 3, 4, 5 and onwards being held via additional Customer Address records.
Such that a new custom attribute can be added to the Contact entity to capture the Contact’s association to a particular address on the Account record – we can then use the added drop-down attribute to let the system user select which Address Line Number to associate the Contact to one of the addresses involved with the Account.
In a solution in this fashion could then be extended to improve the user experience by allowing new Account addresses to be defined from the Contact screen when a user is recording a new Contact.
This is a simple Address Handling extension that we have used in several projects to provide an improved user experience, particularly when users are engaging with larger accounts with multiple addresses and need a process for adding and changing branch addresses directly when updating or adding new Contacts.
This is an overview of some of the ways for handling addresses in MSCRM as the default free-form approach can give rise to questions about how best to use or customise this – particularly the occasional query for ‘doesn’t CRM do this out of the box’ for linking Addresses to Organisations to Contacts.
Be interesting to see whether CRM 5 shakes this up.