As we know, CRM is a highly configurable application. One of the configurable options is to configure the behavior of related records when a CRM record is assigned, merged or some other action is taken. This is a very important concept in CRM because the decisions and actions you take will affect your Organization’s data.
By default, when you install CRM, the cascading relationship of entities is generally set to Parental for actions like Assign, Share, Unshare, Reparent, etc. where there is an option to modify the relationship behavior. Some entity relationships are not available for modifications because there are System dependencies. The “Type of Behavior” will appear as System and you will not be able to modify those relationship behaviors.
So what does this mean? Let’s use the Contact entity as an example to understand how cascading behavior impacts CRM data.
A common action that users might take on a Contact record is to reassign the record. By default, that means that when a Contact record is reassigned to someone else (ownership change) other related record ownership will also be updated to the new Contact owner. Ownership for related records like a Case, E-mail, Task, etc. will change to the new Contact owner for those records that are in an Active or Open status. This can be confusing for the end user when viewing the records because it can appear that someone different from the original owner (created by) created the record. We can modify this behavior to alleviate the confusion and ensure that the related record maintains its original owner.
Here are the steps to configure the cascading behavior of the Contact entity relationship with the E-mail entity. This examples assumes that you know how to open the Contact entity to customize it.
From the Contact entity, select 1:N Relationships. Find the row named Contact_Emails and open it. Notice that the default behavior is set to Parental.
After opening the relationship record, select Type of Behavior and change it from Parental to Configurable Cascading.
Change the remaining behaviors from Cascade All to Cascade None. Save your changes and Publish.
You can repeat these steps for other entities like Accounts, Cases and their relationships with Activities and other CRM entities.
Generally speaking, when I install a CRM application, I modify the system to set the cascading relationship of related Activities (E-mail, Appointments, Phone Calls, etc.) to System Configurable, change the behavior from Parental to Configurable Cascading, and set the Assign, Share, Unshare, and Reparent behavior to Cascade None.
Now that we have CRM 2011, this is much easier to manage as we can create a ‘Default Solution’ that contains the default Cascading behavior desired and import that into each new CRM implementations as a starting point for the project. This is a significant productivity gain.
If you would like to learn more about CRM Customization, check out the 11 Things to know about Customization on the Resource Center. See # 5 for more information about Cascading Behavior.