Configuring Cascading Entity Relationship Behavior

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.


Creating Custom Entities that Work in Dynamics CRM 4

As most know, you can create a custom entity to fit almost any need using the Dynamics CRM application.  I frequently encourage people to think of CRM Entities as forms; forms that have fields to capture data and user input for storing information in a database.  Of course, Entities are much more than that as they can have relationships with other Entities, used to make a ‘connection’ between Entities, used as picklist option type sets for multiple Entities, etc.  However, it can be easier for users to envision the possibilities when thinking of an Entity as a form that contains fields for data collection.

Because it is so easy to create Entities in CRM, systems can quickly get out of control, end up with redundant Entities, form fields, etc.  Therefore, I encourage you to think about a few things before jumping in and creating the Entity.  If you put in a little planning upfront, as it relates to creating Custom Entities, it will pay off for you and your users.

I Thought We Had Something Like That

The first thing you want to do when receiving a request for a new Custom Solution is to review your application and see if you already have something similar.  It could be that all you really need to do is add a new Tab or some additional fields to an existing Entity and that will fit the need.  It is almost always better to use existing Entities rather than creating new ones as that will generally lend to improved productivity and data retrieval.  Users can quickly lose interest in an application if they have to create multiple records of different types that have what appears to be related fields.  This can negatively impact user adoption. 

Naming Conventions & Access Points

Ensure each of the Custom Entity requests you receive include the name that the user wants.  Encourage your users to keep the name simple, 24 characters or less is a good rule of thumb.  This will be the name that displays in the Navigation menu for those Modules you indicate when you create the Entity.  Also, have the user who requested the Entity, identify where they want to see the Entity.  Do they want to see it from the Sales module, Workplace, Service, in the Outlook Offline Client, etc.  This minimizes guess work and helps to ensure a more smooth implementation. 

Obtain all requirements from end users to include sections they want to see on the form with names, tabs with names, where they want attributes (fields) placed, the order, display labels, default values, and attribute requirement settings such as searchable, not required, etc. This will allow you to quickly move through the creation once you’ve completed your prep work.

Although Users will provide you with the Display label for the field / attribute, you will want to come up with attribute names that have a few key elements.  My rule of thumb includes; keep it simple and try to apply relevant names that will help others when dealing with ‘back end’ systems like creating reports, resolving issues, etc.

There are some good tools online that will help ensure you have all the information you need to create the Custom Entity or you can quickly create your own tool using Excel or a similar program.  You can also leverage CRM by creating a Custom Entity for managing End User Change Requests.  This can be valuable for both you and End Users.

Finishing Touches

Once you have the Entity created and the new Attributes or Fields added to the Entity, the form designed and tested, and the Entity published for use, you might think you are done.  However there are a few other items to think about and address before you deliver the Entity to your Users.

One of those areas is Relationships.  I encourage you to go through the Cascading rules related to your 1:N, N:1, and N:N relationships.  I almost always change the existing Cascading rules associated with the Various Activity types like e-mail, task, phone call, etc. to Configurable Cascading rather than Parental and set all values to Cascade None.  If you do not change this then the owner of Activities will change when the Custom Entity record is re-assigned in CRM.  Additionally, if I create new 1:N, N:1 or N:N relationships, I generally use Referential as the Cascading Type of Behavior. This defaults to Cascade None and removes links to related records if the record is deleted.  Since most Organizations want to keep a historical view of the original owner of e-mails, tasks and other related records, I go through the effort to make this change.  This adds a little time upfront but it is well worth it.


Default Views are created for each Custom Entity.  Here are a few suggestions for making the views more User friendly.  

  • Update all System Views. This provides consistency and minimizes confusion when Users move from one View to another (Active, My Active, Inactive, etc.). 
  • Understand and set fields important to users for Preview, Quick Find, ‘New Entity Name’ Lookup, etc.
  • Set View Columns in the Preview, Quick Find, etc. to closely match the other System Views
  • Leave the default field values for the Find columns in the Preview, Quick Find, etc. or select one or two others.  Please note that selecting additional fields can impact performance so take care when making changes.

Updating the various Views related to an Entity can be tedious and time consuming. However, if you want a richer User experience, you will want to take the time to make the changes needed.

Last but not least, you are now ready to go though your Security Roles and apply the right set of access and other security related settings to each Role.

If you follow these basic guidelines when creating Custom Entities, you will hopefully find your CRM application easier to manage and more user friendly.