SharePoint Journey: Relationship Types in Dynamics 365

The data relationship between two entities in the system referred as Entity relationships. In CRM, an user needs to setup relationships, as Dynamics 365 platform is built on a relational database. And CRM customization tools make it easy to create custom entities with no programming experience, but establishing relationships must be understood if the custom and system entities are to work together.

Importance:

Microsoft Dynamic CRM uses entity relationships to manage how data interacts in the system metadata. This metadata design gives the opportunity to customize and manage the data relationships easily.

Lets have a brief view on types of Relationships and its Behaviours in CRM.

Types of Relationships:

One to Many (1:N)
Many to One (N:1)
Many to Many (N:N)
Self-Referential

1. One to Many (1:N): A new 1:N (one-to-many) relationship is created between two

entities(i.e., Parent entity and Related entity) by adding lookup field to related entity. One parent record is associated to many child records with that lookup field, called as parent-child relationships (1:N). A parent record can have many child’s records but a child record must have only one parent record.

Lets build 1:N Relationship between System(Account) and Custom(Test Entity) entity. Suppose I had Custom entity named Test Entity.

Navigate to Default solution > Components > expand Entities. Select Account entity > 1:N Relationships > New 1-to-Many Relationship. It will be redirected to the page of new 1-to-Many Relationship where input fields i.e.,

Relationship Definition section:

Primary Entity: Selected entity is automated.

Related Entity: Select any entity (e.g., Test entity) is to be related.

Name: The default value is to be set by basing on the selected related entity.

Searchable: Select whether this will be searchable to not.

Hierarchial: It refers to the hierarchy settings of selected entity.

LookUp Field Section:

Display Name: Name should be provided.

Name: The default value is automated as per the input value of Display Name.
Note: If Display Name is changed before save, the value in the Name field will not change. Make sure that the Name is meaningful before saving.

Field Requirement: It can opted whether this lookup field value required to be fill or not.

Description: Description about the lookup field that create.

Navigation Pane Item for Primary Entity section:

Entity Name: Select the current entity (e.g., Account)

Display Option: Choose the options listed as follows:

Do Not Display - The other entity will not display an associated view for the current entity.
Use Custom Label - This label will be used for the associated view created for the other entity. It enables the Custom Label field.
Use Plural Name - This will use the plural name of the current entity for the associated view.

Display Area: It is enabled once Use Plural Name or Use Custom Label options are selected in Display Option field. It specifies to choose Display area (i.e., Marketing or Sales or Details or Service) in the navigation pane where relationship label will be displayed.

Display Order: It refers to control where the label will be included within selected display area.

Relationship Behavior section:

Type of Behavior: It can be selected with parental Behavior (In a relationship between two entities, any action taken on a record of the parent entity is also taken on any child entity records that are related to the primary (or parent) entity record).

Click on Save > Publish.

This 1:N relationship will listed as record in component of 1:N Relationships of Primary Entity (e.g., Account).

Note: Once Related Entity is configured to Parent Entity with one Behaviour Type, the same Related Entity don’t be allowed to map with any other Parent Entity using same Behaviour Type.

2. Many to One (N:1): Many-to-one (N:1) relationship is just a reverse of N:1 relationship.

For example: The above created relationship (e.g., Account to Test Entity) would placed in N:1 Relationships listed in the view of Related Entity (e.g., Test Entity).

3. Many to Many (N:N):

A N:N (many-to-many) relationship is relate to link many records from one entity to many records of another entity. This relationship is not availed with primary entity and related entity as there is no such relationship in it because both entities are considered as related entities.

N:N relationship involved with a special entity called a Relationship (or Intersect) entity which has a relationship with each of the related entities. This Relationship entity doesn’t allows to add Custom fields.

Lets create a sample N:N relationship: Products sold to an Account

Navigate to Default solution. Expand Entities under Components. Click on Account entity > New Many-to-Many Relationship. It will be redirected to the page of new Many-to-Many Relationship where input fields i.e.,

Current Entity section:

Entity Name: Select the current entity (e.g., Account)

Display Option: Choose the options listed as follows:

Do Not Display - The other entity will not display an associated view for the current entity.
Use Custom Label - This label will be used for the associated view created for the other entity. It enables the Custom Label field.
Use Plural Name - This will use the plural name of the current entity for the associated view.

Display Order: It refers to control where the label will be included within the selected display area.

Other Entity section:

Entity Name: Default values are automatically set for the Name and Relationship Entity Name fields in the Relationship Definition section once entity is selected from the dropdown field of Entity Name in Other Entity section.

Relationship Definition section:

Ensure the values of Name and Relationship Entity Name, as these names are not changed once saved. And these values must be unique among N:N relationships.

Click on Save > Publish.

Note#1: N:N relationships can’t be availed for all system entities as if the New Many-to-Many Relationship button isn’t present in that entity(on which N:N relationship is build). So both entities must be eligible for N:N relationships while creating a N:N relationship.

Note#2: A many-to-many relationship may also be self-referential i.e., one or more other entity records of the current entity can be related to an entity record of the same entity.

Each side of the entity’s record will displays a multiple associated records of another entity through subgrid.

Account entity record is related to multiple Product entity records through subgrid where click one product (e.g., Test Product) that redirects to open the Product entity record which is related to multiple Account entity records as shown.

4. Self-Referential Relationship:

The entity has a relationship with itself defined as Self Referential Relationship. It allows entity instances to be directly associated with other entity instances of the same type.

Note: One-to-Many relationships and many-to-many relationships can be self-referential.

Lets see simple way of setting up this 1:N relationship as Self-Referential. (Suppose I got custom entity called Test).

Navigate to customization of the entity > 1:N relationships > create new 1:N relationship. It will redirected to the page of new 1:N relationship where provide the meaningful (which explains parent-child relationship) names to lookup field display name and navigation item label name as shown.

Now you can add this field to the main form. Also, can notice the child records by clicking on Navigation button in ribbon.

In TEST entity form, navigate to the Child Records which redirects to Associated View/Sub Grid View of related entity.

N:N relationship as Self-Referential:

Here, two different custom labels for display options are provided. And its meaningful to use something like “To” and “From” to identify the two ends as below.

By clicking on Related To in Navigation Pane will redirects to its Associated view of related entity.

Similarly, by clicking on Related From in Navigation Pane will redirects to its Associated view of related entity.

Issue in self-referential N:N:

Now, examine the usage of self-referential many-to-many relationship. Navigate to N:N relationship section of the customization and create a Relationship information will be seen as below by default.

Now, this is how you can notice from the front end of navigation in the form view which makes confused with same display names.

CRM Behaviors: CRM relationships can be anaylzed using behaviors. Four types of Behaviors are included as follows:

Parental
Referential
Referential, Restrict Delete
Configurable Cascading

1. Parental Behavior: In this relationship between two entities, any action taken on a record of the parent entity is also taken on any child entity records that are related to the primary (or parent) entity record.

This behaviour forces Cascade All(the change is applied to all associated records) effect to all the individual behaviors i.e., Assign, Share, Unshare, Rollup View, Reparent, Delete, Merge.

Here, relationship is considered between System(Account) and Custom entity(Test Entity) using Parental behavior.

Individual Behaviors -

Assign: If parent record is assigned from one user to another user, all the related child records are also assigned as it is blocked to Cascade All effect. And the record owner will be changed.
Note: Before assigning record from one user to another user, make sure that both users possess same security role.

To assign the parent record (TEST) from one user to another user – Click on ASSIGN button in ribbon form.

It will raise a popup where select the user and click on Assign.

After assigned, the changes are obtained i.e., owner is changed as shown.

Share: If parent record is shared with another user, all the related child records are also shared as it is blocked to Cascade All effect.

To share the parent record (TEST) with another user – Click on Share button in ribbon form.

It will raise a popup where add and select the user. Click on Share.

Note: The security role privileges which assigned to another user to be accessed accordingly.

Then the Parent record along with all the child records are shared to another user with granted privileges.

Reparent (referencing attribute of a parental relationship is changed): Suppose If owner of an account and there is an Test entity associated with that account, it inherit read access rights to that Test entity records associated with it. If Parent referencing attribute value for the Test entity record is changed to refer to a different account, the owner of that account inherits read access rights to the Test entity record if the Reparent action is Cascade All.

Here, reparent is done with Test Entity1 record.

And the same Test Entity1 record will shows in another owner of account as change is applied.

Delete: If parent record is deleted, all the related child records are also deleted as it is blocked to Cascade All effect.

Go to parent record and click on Delete then the related Test Entity records are also deleted.

Merge: If two parent records are merged, then all the related records are merged and shown up with Master record.

Select two parent records and click on MERGE button in form ribbon.

It raise a popup where fields are selected that would be placed in Master Account. Click on OK.

The Parent record which was merged with Master record will deactivated and all of its child records are merged as shown.

Rollup View: This behavior allows activities of the related entity would show up in ‘Activity Associated View’ of the primary entity.

Lets create a custom entity “Event” and build a 1:N relationship between Account and Event entities with the selection of Cascade All in Rollup View effect.

Cascade All refers to rollup all activities that related to custom entity can show up in the accounts’ activity associated view.

You can create the activities to related entity record(e.g., Event1) in Activity Associated view.

Now, you can have the activities related to custom entities roll up to account as shown. A single view of all activity history associated with the parent Account record.

Cascade None refers to rollup none of the activities that related to custom entity can show up in the accounts’ activity associated view.

Limitations:

The primary and the related entity must have either 1:N or N:1 custom relationship.
The primary entity for the relationship must be Account, Contact, or Opportunity, as these are the only entity forms where the Activity Associated View appears with Related Regarding Records.
The related entity must have ‘Activities’ options enabled in Customizations.

2. Referential Behavior: In this relationship between two entities, you can navigate to any related records, but actions taken on one will not affect the other.

In this relationship between two entities, any action taken on a record of the parent entity will not affect the child entity records that are related to the primary (or parent) entity record.

This behaviour forces Cascade None(the change is not applied to any other records) effect to the individual behaviors i.e., Assign, Share, Unshare, Reparent.

Remove Link effect is blocked to the individual behavior of Delete.

Cascade All effect is blocked to the individual behavior of Merge.

Here, relationship is considered between System(Account) and Custom(TEST) entity using Referential behavior.

Individual Behaviors -

Assign: If parent record is assigned from one user to another user, all the related child records are not assigned as it is blocked to Cascade None effect. And the owner of parent record will be changed but not child records.

To assign the parent record (Account) from one user to another user – Click on ASSIGN button in ribbon form. The owner of the parent record will be changed but not child records’ owner as shown.

Note: Before assigning record from one user to another user, make sure that both users possess same security role.

Share: If parent record is shared with another user, the related child records are not shared as it is blocked to Cascade None effect.

To share the parent record (Account) with another user – Click on Share button in ribbon form.

Here, the Parent record is shared to another user but not child (TEST) records as shown.

Note: Here, an user can notice the Cascade None effect by providing the different security roles for these two users.

Reparent (referencing attribute of a parental relationship is changed): Suppose If owner of an account and there is a TEST associated with that account, it inherit read access rights to that TEST records associated with it. Even if Parent referencing attribute value for the TEST record is changed to refer to a different account, the owner of that account does not inherits read access rights to the TEST if the Reparent action is Cascade None.

Here, reparent(changed the reference attribute value from Account to Account Par) is done with TEST1 record.

Even TEST1 record is reparented, the same record doesn’t shows in TEST associated view of Account Par as shown.

Delete: If parent record is deleted, then the related child records are not deleted as it is blocked to Remove Link effect.

Go to parent record and click on Delete button in form ribbon.

The child TEST records are not deleted even if the parent record is deleted as shown.

Merge: If two parent records are merged, then all the related records are merged and shown up with Master record.

Select two parent records and click on MERGE button in form ribbon.

It can cleared that above two selected Accounts availed with the child records respectively.

The Accountnew1 record will be deactivated as it is merged with Account record. And all of its child records are merged with the Account record as shown.

3. Referential, Restrict Delete: In this restrict delete relationship between two entities, actions taken on the parent record will not be applied to the child record, but the parent record cannot be deleted while the child record exists.

This behaviour forces Cascade None(the change is not applied to any other records) effect to the individual behaviors i.e., Assign, Share, Unshare, Reparent.

Restrict effect is blocked to individual behavior of Delete.

Note: Parent record cannot be deleted, until to remove its related records.

Cascade All effect is blocked to individual behavior of Merge.

Here, relationship is considered between System(Account) and Custom(Teste) entity using Referential, Restrict Delete behavior.

Note: All individual behaviors of Referential, Restrict Delete is similar to Referential Behavior except Delete individual behaviour.

Delete: Parent record is to delete only after its child records are deleted as it is blocked to restrict effect.

Here, it is cleared that Account availed with two child Teste records.

While deleting the Account record, it raises an error popup says this record could not be deleted because of its existed child records. So, parent record deletion is possible only after its associated child records are deleted.

4. Configurable Cascading: This relationship between two entities allows to define the individual behaviors independently.

This behaviour forces various effects(Cascade All, Cascade Active, Cascade User-Owned, Cascade None) to the individual behaviors i.e., Assign, Share, Unshare, Reparent.

Cascade All, Remove Link, Restrict effects are blocked to individual behavior of Delete.

Cascade All effect is blocked to individual behavior of Merge.

Lets consider a scenario: An user need to assign all active calls to another user but not completed calls.

Build a relationship behavior of Account-Phone Call entity to Configurable Cascading and set apply rule as “Cascade Active” for Assign action.

Here, an Account record is related with its two phone call records(where Test is Active call & Test1 is completed call).

An Account record is assigned from one user ”Monica” to another user ”Parvathi”, then related records of phone call(Regarding), only Active call will be assigned to another user as Assign action is set to Cascade Active.

Here, it is cleared that only Active/Open call is assigned to “Parvathi” user but not completed call.