As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at relationships.
A good start point is often to read / re-read the skills measured statement (shown below). In this we can see that we need to understand relationship types, cascading rules, hierarchical data, entity mapping and connections. In this post I will focus on what I consider to be the “core” relationship concepts. Then in future posts I will expand on these to discuss hieratical data and connections.
Overview
Understanding how to relate Dynamics 365 entities to each other is a key concept when you are customizing the system. Within Dynamics 365 there are several ways to create a relationship between two entities and also multiple types of relationship.
The system entities that come preconfigured with Dynamics 365 already contain many relationships but you can create additional relationships between system and custom entities. It is also possible to amend relationships to alter how they behave. As cascading rules define what will happen to child records when the parent is assigned, shared, deleted etc. For example, if we delete an account what will happen to all of the contacts associated to that account?
Relationship types include;
- One to Many (1:N) or Many to One (N:1)
- Many to Many (N:N)
- Hierarchical Relationships (e.g. Account and sub accounts.)
- Connections
- Customer
Exam Tip: There is no such thing as a one to one 1:1 relationship!
Also, linked to relationships we have field mapping rules. These are applied when one record is created from another. For example, if we create a contact from an account the address, phone number and such like for the contact can be defaulted to the details from the account.
One to Many Relationships (1:N)
One to many relationships are the most common type of relationship in any relational database. It is very common for a parent to have one child or multiple children. Examples of a one to many relationship would include an account having multiple contacts. Or a contact having multiple cases.
With a 1 to many relationship, the child record will have a lookup field that contains the GUID of the parent. A contact for example will have a look up to the account entity.
FYI:
GUID stands for global unique identifier, it is essentially a reference that uniquely identifies any record in your Dynamics 365 database.
Let’s look at a very simple example of a 1:N relationship. Below you can see then on my account I have a sub grid of contacts. Meaning each account (1) can have many contacts (N).
The contacts are the children of the account. On a child contact we can see that it has a relationship back to the parent. We see this in Dynamics 365 as a lookup field.
Many to Many Relationships (N:N)
With a many to many relationships the parent can have multiple children and the child can have multiple parents. One example of this might be competitors and opportunities. As there might be multiple competitors on one opportunity. And each competitor can exist on multiple opportunities. In this scenario on the opportunity we’d have a sub grid of competitors and on the competitor we’d have a sub grid of opportunities.
On the opportunity we see a sub-grid of competitors….
Then on the competitor we see a sub grid of opportunities ….
With many to many relationships we have two approaches to implementation. The first is described as a “native many to many” relationships. The link between competitor and opportunity is an example of a “native many to many relationship”. These are created simply using functionality available directly in Dynamics 365.
The second type of many to many relationship is called a “manual many to many” relationship.
Before thinking about a manual many to many it might be worth considering what is happening behind the scenes when you create a “native many to many” relationship. As the system actually creates a hidden entity that acts as an intersection between the two entities. Effectively each entity has a many to one relationship with the intersection. Which in turn effectively creates a many to many relationship. A manual many to many takes the exact same approach expect the intersection is manually created.
Manual many to many relationships are used when additional fields are needed to capture extra detail. Imagine we have an entity called events and another called delegates. Each delegate could attend multiple events and each event would have multiple delegates. But each time a delegate attends an event we might wish to capture some additional details about that booking. Such as any special instructions for dietary requirements, expected time of arrival etc etc.
When creating a “manual many to many” relationship we actually create an intersection entity. (Meaning it isn’t hidden and additional fields can be added.) The intersection entity will contain the GUIDs from both of the related entities plus any additional fields.
Note: You will often see the GUID field described as the Id field, the terms are interchangeable!
Connections
Connections are essentially a special relationship that allows us to link records in a “non-traditional” manner based on a connection role. Traditional relationships are “hard” relationships, such as linking a case to a contact. Connections are useful to record “soft” relationships, such “is a friend of”, “former employee of”, “went to school with” etc etc. Below you can see an example where my contact “Anne Jones” is a former employee of “City Power”, has a child called “John” and a colleague called “Nancy”.
Customer
Microsoft Dynamics CRM 2016 Update 1 introduced the capability to create a customer field on any system or custom entity.
“Customer” has been a special polymorphic relationship. For example, consider the customer field on cases. It is polymorphic because a customer could be an account or contact, so we can have one field that can relate to either entity.
This relationship always existed in older versions of “CRM” but it wasn’t until CRM 2016 Update 1 that customizers could create customer fields on any entity. It is now possible to create a customer field on any entity.
You can find out more about the customer relationship by reading a post I created when this feature was introduced. (CRM 2016 Update 1 – Customer Field)
Creating Relationships – One to Many
I have used the concept of a custom policies entity in previous posts, so I will stick with that as an example of how to create a one to many relationship. Say I want each account to be able to have one or many policies.
First of all, I navigation to the primary entity. In this example that would be account. So I open my solution (or from the default solution using the customizations option) and then find the account entity. Next I select 1:N Relationships and click “New 1-to-Many Relationship”.
I can then define the details for the relationship. As shown below.
The detail of each field is described below. You should study this and in particular ensure you understand the relationship behavior section which describes how cascading rules work.
Relationship Definition
| Field | Comment |
| Primary Entity | Account, this will have been defaulted as I started from the account entity. |
| Related Entity | Policy, I selected this from the drop down which contained all system and custom entities. |
| Name | I accepted the default name but you can change the name when creating the relationship. But not afterwards. |
| Searchable | This option will default to “yes” and is typically left like that. Setting searchable to no will remove the relationship from options available in advanced find. |
| Hierarchical | Here we can define hierarchical relationships, I will cover these in a later post. |
Lookup Field
| Field | Comment |
| Display name | The name of the relationship will default to the name of the primary entity. Meaning I will have a lookup field available on policy that the user will see named “Account”. You can however change this name if required. |
| Name | This is the name of the lookup field that will show on the related entity. In this example this is “new_accountid”. The name can be changed as the relationship is created but once created it cannot be changed. |
| Field Requirement | As with any field I can make the lookup to be optional, business required or business recommended. In my example, I left it as optional. Meaning if a policy is created relating to an account is not mandatory. I hope you can see that it may actually be quite common to change this to be business required! |
| Description | A free text description. This has no functional impact but will show to the users if they hover their mouse over the ID field. |
Navigation Pane Item for Primary Entity
| Field | Comment |
| Display Option | This will default to “Use Plural Name”. Meaning I would have an option called “Policies” in the navigation of my account. Other options are do note display and use custom label |
| Custom Label | This option isn’t available unless the display option is set to user custom label. Then the label entered here will show in the navigation. |
| Display Area | Options include Details, Marketing, Sales and Service. These correspond to the out of the box areas in the CRM site map. When users look at the navigation options from the parent entity they will see options groups into these areas.
Note: “Details” is actually shown to the users under a heading called “Common”. And is the default option. |
| Display Order | The display order can be used to define the order of navigation items in the navigation pane. |
Relationship Behavior
| Field | Comment |
| Type of Behavior | The default when creating a custom entity will be referential. Other options include parental, referential restrict delete and configurable cascading.
|
| Assign | Defines what will happen if the owner of a record is changed.
Read-only, unless configurable cascading is selected. The assign, as with share, unshare, reparent and merge has the following options available.
|
| Share | Defines what will happen if a record is shared with another user or team.
Read-only, unless configurable cascading is selected. |
| Unshare | Defines what will happen if a record is unshared with another user or team.
Read-only, unless configurable cascading is selected. |
| Reparent | This option is actually similar to share / assign. It is triggered if the parent of the child is changed. For example, if set to cascade all, the owner of the newly assigned parent would inherit access to the child. But if cascade none was set the new owner would not inherit access.
Read-only, unless configurable cascading is selected. |
| Delete | Defines what will happen if the parent is deleted.
Read-only, unless configurable cascading is selected. Has a different set of cascade options which include;
|
| Merge | Defines what will happen to the children if the parent is merged with another parent.
Read-only! This option is always cascade all. |
Create Native Many to Many
Creating a native many to many relationship is actually very similar to creating a one to many relationship. Except the many to many relationship does NOT have any cascading rules.
I hope this information will be useful to anyone preparing for the MB2-716 exam. But as always I should stress that you can’t rely on theory alone to pass the exam. Getting hands on experience is also essential.
In future posts I expand on these concepts by discussing entity hierarchical relationships and connections.
Microsoft Dynamics 365 
Pingback: MB2-716 Certification: (Microsoft Dynamics 365 Customization and Configuration) – Revision Guide | Microsoft Dynamics 365 and Unified Service Desk