Cascading Rules in Microsoft Dynamics CRM

Roshan Mehta, 22 June 2011

In my previous post, we covered the different types of relationships available in Microsoft Dynamics CRM. We can also define what are known as cascading rules which allow us to have better control over our CRM records and any records which may be related to them. In this post, I will cover the different types of cascading rules and explain how and when each of them would be used.

 Cascading Rules in Microsoft Dynamics CRM

Microsoft Dynamics CRM allows us to control what will happen to related records when a CRM user takes action on a parent record. Examples of these actions include:

1. When a record is assigned to another User.
2. When a record is shared with another User.
3. When a record is unshared.
4. When a records parent changes.
5. When a record is merged.
6. When a record is deleted.

These actions are controlled by the following cascading rules:

Cascade All – If one of the above actions is performed on a record, the same action will be performed on all related records. For example, if a user deletes an Account, all related Contacts within that Account will also be deleted.

Cascade Active – If one of the above actions is performed on a record (with the exception of a record being deleted), the same action will be performed only on related records which are in an active or open state. Deactivated related records will not be affected. For example, if an Account is assigned to another user, all related active Contacts within that Account will also be assigned to the new user.

Cascade User-Owned – If one of the above actions is performed on a record (with the exception of a record being deleted), the same action will be performed only on related records which are owned by the same user. For example, if an Account is assigned to another user, all related Contacts which are owned by the same user will be reassigned.

Cascade None – If one of the above actions is performed on a record (with the exception of a record being deleted), none of the related records will be affected. For example, if an Account is assigned to another User, no related Contacts within that Account will be assigned to the new User.

Remove Link – This rule is only available for the delete action. If a record is deleted, any related records will not be deleted. CRM will remove the link between the record and its related records.

Restrict – This rule is only available for the delete action. If a user tries to delete a record that has related records, CRM will prevent the user from deleting the record.

It is important to note that a CRM user needs to have security privileges for the record type of the record they are performing an action on as well as the record type for any related records of which there is defined a cascading rule. For example, if a user has the privilege to delete an Account but not Contacts, the user will not be allowed to delete the Account if it has related Contacts.

Microsoft Dynamics CRM makes it easy for us to define cascading rules by providing a number of pre-configured relationship behaviours.

Parental – All operations are set to “Cascade All”. This is the default configuration for custom relationships.

Referential – All Operations are “Cascade None” except for the “delete” and “merge” actions.

Referential Restricted – This is the same as a Referential Relationship except that a record cannot be deleted if it has related records.

Users can also define their own cascading rules for a custom relationship by using the Configurable Cascading option.  In my next post, I will cover relationship mappings in Microsoft Dynamics CRM.