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.
Cheers
Donna Edwards 
If cascade-all was configured for the example that you gave, contact – account, when you make this configuration change, will it revert back the ownership? or are those records ownership changed for good?
If I understand you question correctly, making the cascading change affects only records where the ownership changes moving forward. It does not affect records that were previously re-assigned.
I have an interesting case. Cascade sharing was configured. It was then removed and then added again.
Now that it is in place again, the child records are not in sync with the shared parent records.
eg: 1 portfolio has many transactions.
The portfolio is shared with a team but the transaction records are not visible to the users on that team unless I unshare and re-share the portfolio record.
There are too many records to do this with manually. Is there a way to push the cascade ?
You can check the SDK and see if there is a way to set the Cascading behavior via Code.
Can i use this cascading when i deactivate a record then the related/child records/record should be deactivated and vice versa.
Cascading will not change the record status. You’ll need to use a workflow or plug-in depending on requirements.
Can I just say what a aid to search out someone who actually knows what theyre talking about on the internet. You positively know the right way to bring an issue to light and make it important. More folks must learn this and perceive this facet of the story. I cant consider youre no more standard because you positively have the gift.
Hello. I have an issue where I want to share an account but don’t want related contracts to become visible to the one I share the account with. So I changed the cascading behavior from Parental to Configurable/Cascade None. However, the person I share the account with is able to see the contract. Any ideas on how to solve this? Thank you in advance.
Ensure you have changed the Cascading Share value to None on all Relationships not just the Account / Contract. It could be that some other related Account record is cascading the share down to the Contract. Also understand that the user might be able to see the Contract because the user has privileges that allow this, the Contract record was previously shared with the user or something different.
Have a look through this and see if it helps:
msdn.microsoft.com/en-us/library/gg334673
Sharing and Inheritance
If a record is created and the parent record has certain sharing properties, the new record inherits those properties. For example, Joe and Mike are working on a high priority lead. Joe creates a new lead and two activities, shares the lead with Mike, and selects cascade sharing. Mike makes a telephone call and sends an email regarding the new lead. Joe sees that Mike has contacted the company two times, so he does not make another call.
Sharing is maintained on individual records. A record inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, a record can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent.
Removing the share of a parent record removes the sharing properties of objects (records) that it inherited from the parent. That is, all users who previously had visibility into this record no longer have visibility. Child objects still could be shared to some of these users if they were shared individually, not from the parent record.
Hello Donna,
Do you know if its possible to turn off the feature: “when we delete
a contact it also will delete connected cases. I’ve tried to change the 1:N relationship to Configurable cascading but I can’t choose “Cascade None” for the Delete Behavior (its grayed out)
You would have to update the Contact on the Case record first. If you think about it, deleting a Contact and leaving related records would break the relationship thus leaving orphaned records in the database. The system will not allow that for a few reasons.