Approaches for Managing Addresses using MSCRM

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:

Entity Relationship Diagram showing the relationships between Address, Contact and Account entities in MSCRM

Entity Relationship Diagram showing the relationships between Address, Contact and Account entities in MSCRM

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.

Address 1 Field Mappings between the Account entity and the Contact entity in MSCRM

Address 1 Field Mappings between the Account entity and the Contact entity in MSCRM

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:

List of Contacts in MSCRM attached to an Account listed by Address

List of Contacts in MSCRM attached to an Account listed by Address

From here, users of the solution can select groups of Contacts at a time to peform a bulk update for Office Address changes:

Selecting a group of Contacts attached to an Account to update an Office Address

Editing a group of Contacts attached to an Account via a bulk update in MSCRM

Bulk Editing a set of Contacts to update the shared Office Address

Bulk Editing a set of Contacts to update the shared Office Address

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:

  • Additional Addresses are not used. (these can often be hidden by hiding the ‘More Addresses’ Nav Bar)
  • Single Account record to represent the Address fields for the Head Office Address of an Organisation
  • Contact’s Address fields are used to store other Office Addresses within the Organisation (based on the office that he or she works out of), and should be kept up to date via single edits (for Contact’s moving between Offices) or bulk edit (for a Branch or Office moving address)
  • 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.

    Showing an example hierarchy of Account and Contact records

    Showing an example hierarchy of Account and Contact records

    Account Hierarchy represented in MSCRM

    Account Hierarchy represented in MSCRM

    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.

    Activity Rollup for an Organisation with several Branches represented as Accounts

    Activity Rollup for an Organisation with several Branches represented as Accounts

    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 Addresses are not used.
  • Multiple Account records to represent the Addresses of the different Branches or Offices of an Organisation
  • Each Contact is associated to a single Branch or Office and so the Contact Address fields should be the same as the Branch or Account that the Contact is associated to
  • 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.

    Entity Relationship Diagram showing Contacts associated to either an Account or Customer Address

    Entity Relationship Diagram showing Contacts associated to either an Account or Customer Address

    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.

    This drop-down attribute can then be used in conjunction with Plugin Logic to ensure that changes to the address involved at the Account level are copied to all the associated Contacts, with Form Scripting via JavaScript implementing the User Interface the user interface of populating the Office Address Selected drop-down list with address options possible for the Account involved.

    Screen impression showing how a user may select a Branch or Office Address for a Contact through MSCRM Development

    Screen impression showing how a user may select a Branch or Office Address for a Contact through MSCRM Development

    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.

    Creating a new Account Address directly from entering a new Contact

    Creating a new Account Address directly from entering a new Contact

    New Account Address as a result

    New Account Address as a result

    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.

  • Additional Addresses recorded per Account to represent additional Branches or Offices
  • Single Account record in MSCRM per Organisational entity
  • Multiple Contacts associated to a single Branch or Office through a Office Address Selected relationship implemented via custom development
  • 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.

    Advertisements
    This entry was posted in Consultancy, MSCRM, Technical. Bookmark the permalink.

    3 Responses to Approaches for Managing Addresses using MSCRM

    1. The following article on Matt Wittemann’s excellent long-running MSCRM blog provides further detail about how addresses are managed by the MSCRM platform.

      http://icu-mscrm.blogspot.com/2009/05/crm-address-entity-theres-more-to-it.html

    2. Adam Vero says:

      The Activities rollup associated view on an Account (and other similar ones, eg Opportunities) only shows up activities regarding entities which are linked directly to the Account.
      So, activities ‘regarding’ sub-accounts or contacts will show up, but not activities regarding contacts of the sub-accounts.
      For this reason, I would generally only advocate using sub-accounts where there is a real relationship ie a parent company which owns a subsidiary, rather than as a workaround for address management. Of course, some individual circumstances may vary.

    3. Ashis says:

      can u send me the above example javascript code?

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s