MB2-712 Certification: (Microsoft Dynamics CRM 2016 Customization and Configuration) – Relationships

In the post I will explain the concepts behind entity relationships in Microsoft Dynamics CRM2016, a topic you will need to understand when revising for the Customization and Configuration certification. (MB2-712)

A key part of the MB2-712 exam is to understand how to relate CRM entities to each other. Within CRM there are several ways to create a relationship between two entities and also multiple types of relationship.

The system entities that come preconfigured with CRM 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;

  • Many to One (N:1) or One to Many (1:N)
  • Many to Many (N:N)
  • Hierarchical Relationships (e.g. Account and sub accounts.)
  • Connections

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 no children, 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.

Then the parent can contain a sub grid list all of the children. An account for example may contain a sub grid containing multiple contacts related to that account.

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.

The opportunity has many competitors ….


The competitor also has many opportunities …..


Now 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 the CRM interface.

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 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 booked. 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.


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”.

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.

Section Field Comment
Relationship Definition 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 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 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 Type of Behavior The default when creating a custom entity will be referential. Other options include parental, referential restrict delete and configurable cascading.

Parental means, if the parent is assigned, deleted (etc) the change will be cascaded down to all children. In my example, this would mean the policies would be deleted if the account was deleted. Etc.

Referential, means changes are not cascaded down. In terms of a delete this would imply removal of the link between entities.

Referential Restrict Delete, is essentially the same as referential. Accept you can’t delete the parent if it still has children.

Configurable Cascading, selecting this option allows you to manually set the cascading logic for each option. (Assign, share, delete etc.) With the other types of behaviour, the cascading option sets are read only. But selecting this option will allow each one to be individually controlled.

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.

  • Cascade All, the change will be applied to all children.
  • Cascade Active, the change will be applied to all active children, inactive records will be ignored.
  • Cascade User Owned, the change will be applied to all child records owned by the owner of the parent record.
  • Cascade None, none of the changes will be cascaded.
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;

  • Cascade all, deleting the parent will delete all of the children.
  • Remove Link, deleting the parent will keep all the children but the link to the parent will be removed.
  • Restrict, it will not be possible to remove the parent without removing or re-assigning all of the children first.
Merge Defines what will happen to the children if the parent is merged with another parent.

Read-only, unless configurable cascading is selected.

Create Native Many to Many

Creating a native many to many relationship is actuallyu 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-712 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. J

One thought on “MB2-712 Certification: (Microsoft Dynamics CRM 2016 Customization and Configuration) – Relationships

  1. Pingback: MB2-712 Certification: (Microsoft Dynamics CRM 2016 Customization and Configuration) – Revision Guide | Microsoft Dynamics CRM and Unified Service Desk

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