Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
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.
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;
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.
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 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”.
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.
Navigation Pane Item for Primary Entity
Note: “Details” is actually shown to the users under a heading called “Common”. And is the default option.
Read-only, unless configurable cascading is selected.
The assign, as with share, unshare, reparent and merge has the following options available.
Has a different set of cascade options which include;
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.
Business Applications communities