blogs & Things

The Problems With Addresses In Microsoft Dynamics 365

Craig Seymour – cloudThing, Dynamics Practice Lead

I recently had to deal with a situation in which a customer had some requirements relating to addresses in Microsoft Dynamics 365, which wasn’t handling them very well. 


In figuring out the best approach to meet their requirements, I learned a little more about addresses than I knew before, particularly around how Microsoft Dynamics 365 handles Address Types that I thought I’d share with you all…

A Bit Of Background First

The customer’s requirements were that:


  • They wanted to attach ‘Offices’ to an Account i.e. physical locations where the Account has operations but are not a child account.
  • They wanted Contacts’ work addresses to be linked to an Office at their associated Account, to minimise data entry when a contact works at more than one office.
  • They wanted to tag Offices (and Contact addresses) as being one or more of Registered Address, Mailing Address, Invoicing Address and Shipping Address.


On the face of it, this sounds like a job for the system Address entity, as both the Account and Contact entities in Dynamics 365 support having multiple associated addresses, and have a standard, customisable set of types including ‘Bill To’ and  ‘Ship To’.

However, the implementation of Addresses has a lack of flexibility which prevents us using them to meet the above requirements; in particular Addresses cannot have custom relationships added to them, so address information cannot be shared within or between entities and a single Address cannot be tagged with multiple purposes (e.g. Billing AND Shipping).


So, a custom entity, perhaps?

But Addresses are tightly integrated into Microsoft Dynamics 365 and it’s reasonable to assume that processes and 3rd party integrations are expecting them to be there and working ‘normally’.


But before we dive into customisation, we need to make sure we properly understand how the system Address entity works.



First of all we read what’s already been written:



Building on those two articles and digging a little deeper, we arrive at the following understanding…

Embedded and Related Addresses

  • Both the Account and Contact entities support the concept of having any number of addresses, stored as a 1: many link to the system Address entity.
  • In both cases the Account and Contact entity also present a set of address fields embedded in the record – Accounts have 2 sets and there are 3 for Contacts.
  • Behind the scenes, these ‘Embedded Addresses’ (my terminology, not Dynamics 365) are stored in the system Address entity. Updates to the embedded address fields or to the corresponding Embedded Address record are automatically mirrored to the other end of the relationship.
  • When an Account (or Contact, but I’ll just use Account from here on where there is no difference) is created, blank Address records are automatically and created and linked to the Account. Furthermore, the id of the Address records created is set in the address1_addressid and address2_addressid fields in the Account record.  If you delete these system managed addresses, you will get errors when trying to update the Account address fields.
  • The default views against the Address entity specifically exclude the Embedded Addresses, using the ‘addressnumber’ and ‘objecttypecode’ fields on the Address:

addressnumber: this is an Integer value with no documented significance; however empirically we observe that an Embedded Address record created to store the Address1, 2 (and 3) fields have a corresponding ‘addressnumber’ value.

Upon creation, non-system Addresses have their addressnumber set to 1 more than the greatest existing value. However, it can be modified after creation to any value.

objecttypecode: this field is set to match the entity object type for either Account (1) or Contact (2).

Address Types

  • By default, Microsoft Dynamics 365 allows an Address to be given a single type. The default Option Set labels and values are tabulated below. Although the values are the same, the Option Sets specific to each field, and are not shared.
    The type is set in the ‘addresstypecode’ field, and each Embedded Address has a corresponding field (e.g. ‘Address1_AddressTypeCode’).
  • When an Embedded Address is created, it sets the Address addresstypecode to match that in the Embedded Address, matching on the Option Set’s value. The addresstypecode on the Embedded Addresses defaults to ‘Unassigned Value’ for addressnumber 1 and 3, but to ‘Default Value’ for addressnumber 2.
  • The Option Sets can be edited in the usual way, and so long as D365 finds matching values between the Option Sets in the Contact/Account entities and in the Address entity, it will set them in the Address record. Otherwise it will set the value to null.

Address 2 behaviour

  • Of the Embedded Addresses, Address2 is the only one with a default value set, which is aptly (or confusingly!) labelled as ‘Default Value’.
    This has the Option Set value of 1, which corresponds to the Address entity’s AddressTypeCode of ‘Bill To’ – so by default, the Account’s Address2 has type ‘Default Value’ and the corresponding Address is set to ‘Bill To’.


*Note that if the System Preference for Outlook Sync  is set to “Synchronise all three addresses (Business, Home, Other) in Outlook Contact” then the ‘Home’ address will therefore be the ‘Bill To’ address, which may not be the desired behaviour.

Relating to Other Entities

  • You cannot add your own relationship to or from the Address entity.

Addressing the Limitations

So, as discussed above, to meet the customer’s requirements we can’t customise the Address entity and we can’t replace it with a custom entity.

But, we can steer a middle course: create our own custom entity ‘Site’ and ensure that it synchronises into (and duplicates) the Address records where necessary.


From the user’s point of view, they are creating and interacting with Sites instead of Addresses; but processes and 3rd party systems which are unaware of the Sites entity are able to interact with the Address entity; as are users who do an Advanced Find against the Account/Contact/Address entities.

For the specific customer which set us on this journey, we elected to setup 3 individual lookups to Sites for an Account’s Primary, Invoicing and Shipping addresses and to sync those to Address records with the AddressTypeCode set to the default ‘Primary’, ‘Bill To’ and ‘Ship To’ values.

We added some business and front-end logic to make it easy for users to set some/all of these to be the same.

As our convention we chose Primary and Invoicing to be the 2 embedded addresses, and Shipping as a ‘normal’ Address.

All other Account addresses we put in a Sites sub-grid and did not sync to Addresses.

For Contacts, it was enough to set and sync only the ‘Primary Address’, with all other addresses simply created as sites.

The ‘Primary Address’ is a lookup initially is filtered to allow the user to easily link to a Site on the Account but they can create a new Site if they wish – but by default, any Site created from a Contact is deemed to be private to the Contact and is not linked to their Account.”

This is quite a simple solution but as with any situation with synchronisation involved, there is some detail which we need to keep in mind:


  • To give the best chance of a flawless integration with 3rd party systems, we need to make sure we set the ‘Type’ correctly on our Addresses.
    So if I set my Site as the ‘Invoicing Address’ or the ‘Billing Address’ or whatever other convention the requirements specify, then the Address I create off that should be given the type ‘Bill To’.
  • When a Site is linked to multiple Contacts, they will each get a copy of the Site’s address data into their own individual Address records – we need to remember to update all of those records if the Site data is changed.
  • If a Site is deleted, we can normally delete all the Address records created from it. However, if the data was synchronised into the Address1/2/3 entities, then we need to clear the data rather than delete the record.
  • It’s tempting to think we can treat Addresses as a target only, as they are a copy of the Site data; but we need to remember that if some process we don’t know about updates an Address, it needs to get reflected up to the originating Site.


cloudThing are experts in solving complex business problems with Microsoft Dynamics 365. If you’re ready for a Cloud-based migration or looking to make the most out of Dynamics 365 then get in touch today for a chat…

More blogs & Things

More blogs & Things

James Crossland in NonProfit

AI + Automation: Reducing Donor Churn & Maintaining Sponsor Interest

Churn management is a vital element of any marketing strategy, and the NonProfit sector is no exception. Knowing what to track and having a joined up view of all your donations data is vital for getting this right, and also opens the door to building innovative data-driven campaigns.   At our recent DataScience and Transformation in Charities […]

James Crossland in NonProfit

Dynamics 365 In NonProfit’s

Charities have unique funding concerns, and an obligation to spend as much as possible on their chosen cause. However, an investment in technology can offer ROI in the form of more than just improved fundraising. Dynamics 365 can help rework complex business processes, ensure compliance with stringent safeguarding and financial regulations, as well as consolidate […]

James Crossland in Tech

8 Ways Your Business Can Increase Turnover With Big Data

Understand how Big Data and Data Science can transform your business…   Big Data is the phrase that’s used to categorise any data that’s too large, complex, cumbersome or complicated to be managed and processed by conventional technology. To put that into a relatable context; being able to recommend your customers content, products or offers based […]

James Crossland in NonProfit

How To Reduce Donor Churn In NonProfits

Reducing Donor Churn doesn’t have to be a big task but does need to be a fundamental part of a NonProfit’s day to day processes   What Is Donor Churn? Donor Churn is the likelihood of an individual stopping their donations to a charitable cause for a variety of different reasons resulting in the non-profit organisation […]

James Crossland in Tech

Agile: Cutting Costs, Improving Quality & Accessing Talent

After using Agile to develop software products for several years, we thought we’d share the challenges we encountered at the start, what we did to change and the results we saw (which were ultimately uplifts in quality and efficiency)…   My development team has been using Agile to develop software product since 2007. Personally, I’ve seen many […]

James Crossland in Tech


What’s the difference between UI and UX?   Simply put UI (or User Interface) are the pages, screens, buttons, icons and any other visual aspects of a website or App that let you interact with it… or to expand on that into the non-virtual world… UI is how you experience using something – For instance in opening a fridge, […]