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 Dynamics 365 handles Address Types that I thought I’d share with you all…
The customer’s requirements were that:
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...
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).
*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.
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:
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…
Are you struggling with Microsoft Dynamics? Our Dynamics 365 experts are here to help so feel free to try and stump them with any technical problems you're having... They love a challenge!