Microsoft Dynamics 365 – Relationships
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 R
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 view of an opportunity that has a lookup of related Competitors
In the images above and below, you can see that competitors have
Cascading Rules
The classic example for cascading rules is “If I delete an account, what should happen to the Contacts that are associated with
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
| Parental | This cascades all actions on the parent account to the child account. |
| Referential | Changes will not be cascaded down. |
| Referential, restrict delete | This makes it so that you can’t delete the parent if it still has children. |
| Configurable Cascading | This allows you to select from the following options below. |
Acts that fire Cascades
| Assign | This allows you to assign records should the owner be changed |
| Share | This says what will happen if a record was shared |
| Un-share | This says what will happen if a record was unshared |
| Re-parent | This says what will happen if the parent of a child record is changed |
| Merge | This says what will happen to the children if the parent account is merged with another |
| Delete | This says what will happen if the parent account is deleted |
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.
No comments:
Post a Comment