This post is part of a series that I am creating which go over Customizations as they relate to Microsoft Dynamics 365.

Microsoft came up with Relationships so that there is a way around security. They did this in part because they wanted to maintain a security model while letting certain Entities share data. Only items that we want to be related to one another will be. There are several ways to relate different Entities. We will be going over the different ways during this post.

Microsoft Dynamics 365 comes with many out of the box Relationships. These Relationships don’t have to stay, but they do support the basic functionality of Dynamics 365. We are the Customizers, we can make Dynamics 365 do whatever we want it to.

Types of Relationships

One-to-Many (1:N)

This type of a relationship is used much more often than many-to-many.

A one-to-many relationship can be displayed either as a one-to-many or a many-to-one. N:1 relationships are the same as 1:N, but N:1 are a shortcut. This is because in the metadata, only 1:N relationships exist.

With a one-to-many relationship, the child record will inherit the parent records (GUID). This is what forms the basis for lookup fields. Without this security bridge, lookups would not be possible.

For example, one Account might have many Contacts that we can access via a lookup field.

Many-to-Many(N:N)

Many-to-Many relationships don’t have cascading rules. Instead, they implement a hidden Entity that we cannot access. This entity has two 1:N relationships, one going each direction. So whenever we implement a N:N relationship, we are really using two 1:N’s, via a hidden Entity.

A parent Account can have multiple children and a child Accounts can have multiple parents.

In the images above and below, you can see that competitors have share an out of the box N:N Relationship with Opportunities.

Cascading Rules

The classic example for cascading rules is “If I delete an account, what should happen to the Contacts that are associated with said Account?”

This is what cascading rules do, they set up a set of instructions for the system should your link be broken. By default, the “type of behavior field” is set to referential.

Types of Behavior

Acts that fire Cascades

Configurable Cascading for assign, share, reparent

• Cascade all – This cascades all actions on the parent account to the child account.
• Cascade active – This cascades the actions on the parent account to all child records that are related and active.
• Cascade user owned — This cascades the actions on the parent account to all child records that are related and owned by the same user.
• Cascade none – Nothing happens if the parent record is deleted.

Configurable Cascading for delete

• Cascade all – deleting the parent deletes the children
• Remove link – deletes the link to the children if the parent is deleted
• Restrict delete – you can’t delete the parent because it has a link to child records

Connections

Connections are a new way that we can link Entities. This is really useful if we wanted to store information that isn’t too formal. A good example is if we wanted to remember that two employees are father and son.

Customer

The customer field can be inserted in any Entity. This allows a lookup between an Account or a Contact on any Entity.

Entity Mapping

Entity Mapping is a huge subject that deserves an entire post. To give you a taste of it, Entity mapping allows us to auto-populate fields from a related record. For example, if we were to create an email, we could auto-populate the names, addresses, and any information that we want to send of the Account that we are sending the email to. This is an incredible time saver.

The definitions are based from the Microsoft Dynamics 365 website. I encourage you to look at them. These documents are helpful when you want to learn more in depth on any subject.