Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

HCLTech Microsoft Business Applications Practice Blog

for Dynamics 365, Power Platform and the rest of the Microsoft technology stack

Best Practice: Using Built-in Address versus Custom Address Entity in Dynamics CRM

Post Author: HCLTech |

One of the basic rules when deciding between using Dynamics CRM features out of box (OOB) versus creating a custom address entity is to verify that the OOB solution works with your business model and expectations. Often times there are trade-offs, so it is important to understand what they are in order to decide the best course to take.

Custom Address Entity
One example is the custom Address entity in CRM, also known as More Addresses on the CRM record. The main purpose of this Address entity is to create one or multiple addresses for Accounts and Contacts. For example:

  • Multiple shipping addresses for one billing address
  • Multiple billing and shipping addresses for one franchise with many different locations

OOB Address entity displays in the Sales entity and allows for easier maintenance. It is stored in the same tables as address1 and address2 fields on Accounts and Contacts which makes reporting on the OOB Addresses entity much easier. OOB Address entity will also work in situations where there is a need for API for address validation. However, we cannot create any other relationships to the OOB Address Entity other than what is OOB, unless we use a work around, such as custom coding.

One of the main reasons for creating a custom entity is for situations when we want to create N:1 relationships to the Address Entity. This includes, for example, lookups to the Address Entity which you cannot do with the OOB Entity, such as:

  • Quotes
  • Orders
  • Invoices

However, we have to understand that by opting for a Custom Address entity we are losing some of the OOB built in functionalities described above. Therefore it is always important to weigh pros and cons of each option before deciding on one.

See below a table summarizing the benefits of both options:


OOB Address Entity

Custom Address Entity

Easier maintenance


Not recommended

Easier reporting on addresses


Not recommended

API for address validation


Not recommended

Create N:1 relationships

Not recommended




Adding OOB Address Entity to the Command bar

The OOB Address Entity does not appear on the command bar by default.

Best Practices: Using Built-in Address versus Custom Entity

To add it to the Command Bar, open the Account Form.

Best Practices: Using Built-in Address versus Custom Entity



Click the "Navigation" button on the top.

Best Practices: Using Built-in Address versus Custom Entity

Drag the Addresses from the Relationship explorer on the right to the Navigation on the left. Save and Publish.

Best Practices: Using Built-in Address versus Custom Entity


Your Command Bar will now display the Addresses.

Best Practices: Using Built-in Address versus Custom Entity

Proceed with adding New Addresses, if OOB Address Entity is what you have decided to use.

Best Practices: Using Built-in Address versus Custom Entity


The decision to go with the OOB Address entity versus a Custom Address entity should be always made after carefully considering the business requirements. Our first recommended option is to make the OOB entities work with what we need, as they come with a lot of built-in functionalities that will need to be mapped, recreated and managed for any added custom entities.

Stop by our main blog page for even more fantastic Dynamics CRM tips and tricks. Or here for more info on workflows. And remember…

Happy CRM'ing!


By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

6 comments on “Best Practice: Using Built-in Address versus Custom Address Entity in Dynamics CRM”

  1. Joe,

    I'm curious about your mention of "API for Address Validation" when discussing the Out of the Box address entity. Are you suggesting that there are built-in address validation API's for the address entity, or that they are easier to use with the built-in address? I just wanted to make sure I wasn't missing a feature that was already there. I've implemented custom address entity and validation using SmartyStreets without much complexity.


    1. Hi Larry - Yeah - nothing out of the box as far as we know. We have seen a few address verification tools that tie with no code to the out of the box address entity, but if using a custom entity would take custom code.

  2. Hello, have following problem.
    Primary and secondary addresses are already build.
    Now i create third address and need set it as primary.
    How could this be done programatically using CRM SDK ?

    1. Hi Libor - yes - you can do this via the sdk in a plugin or javascript. if this is something real time a user may do, then java script probably better method.

  3. i want to add a lookup of custom entity on address in crm 2015, but neither i can add any relationship nor direct lookup.what should i do ?

  4. If I use OOB functionality for Dynamics 365 can I change the field type in the fly out menu? I want to make the State/Province a list of values that must be selected

PowerObjects Recommends