What does mean the Cascade Option on Relationships in Microsoft CRM 3.0 ?

Hi guys,

Recently I’ve been asked a number of questions about the Cascading options in CRM

Thus I wanted to make a quick sum up which can demystify all this a little bit J

I tried to explain what all the options mean: Assign,Share,Reparent,Unshare and all the Cascade Choices All,None,Active,UserOwned with simple examples.

Cascade Options

 

Cascade All: The operation triggers full cascading on the specified relationship for that operation.

Example:

RelationShip: Account->Contact

Share: Cascade All

UserA creates AccountA (Root), ContactA1 & ContactA2(Childs)

UserA Share AccountA to UserB

All the objects, AccountA (Root) + All childs (ContactA1 & A2) will be shared to UserB.

(There is no exception here or cascading restriction for the childs.)

Cascade None: The operation triggers no cascading at all on the specified relationship for that operation. We only take care of the Root object as opposed to Cascade All

Cascade Active: The operation triggers cascading on the relationship, but it cascades only to rows in the "Active" state for that particular relationship.

(What ‘Active’ means is determined by looking at the statecode for the entity instance.). This means the only criteria for this cascade to be fired is the State of the record.

Example:

RelationShip: Account->Contact

Share: Cascade Active

UserA creates AccountA (Root), ContactA1 & ContactA2(Childs)

UserA Deactivate ContactA2

UserA Share AccountA to UserB

Only AccountA and ContactA1 will be actually shared to UserB.

ContactA2 has been deactivated, thus it doesn’t match this Cascade Active (only) criteria.

Cascade User-Owned: The operation triggers cascading on the relationship, but it only cascades to rows that are owned by the same owner as the root object.

Example:

Relationship: Contact->Task

Assign: Cascade User-Owned

UserA creates ContactA (Root), TaskA1 & TaskA2 (Childs)

UserB creates TaskB1 (Child).

If ContactA is assigned now to NewUser, TaskA1 and TaskA2 only will be assign to the new user too.

Because TaskB1 is not owned by UserA, it doesn’t match the Cascade User-Owned criteria.

Assign/Share/Unshare actions on which we can set these cascading options should be straightforward to understand. they are triggered only by Assign/Share/Unshare operations only. Thes means that if you want to perform one of these operation you specifically go to the Action Menu and trigger what you want (Share,Assign,etc..)

Reparent is surely the less intuitive action. It applies on Create/Update of an object when a parent is specified/removed.

This finally happens all the time when you use CRM, let’s imagine you create a Task within a specific contact, you are implicitly changing the parent of your task from NULL to something, thus you are here triggering the Reparent action without actually realizing it.

Reparent is important in CRM and is mainly the feature which ensure you that when you are an owner of a Root object BY DEFAULT you automatically have inherited access to the childs even if the childs are created by someone else and you have User Only read privilege on the child entity.

Example:

Prerequisite: UserA has UserOnly privilege on Opportunity.

Relationship: Account->Opportunity

Reparent: Cascade all

UserA creates AccountA (Root), OpportunityA1 & OpportunityA2 (Childs)

UserB creates OpportunityB1 (Child).

UserA will automatically be given access to OpportunityB1 even if he has UserOnly privilege on Oppportunity.

NB1: If you don’t want UserA to be given access, the cascade option shall be set to Cascade None*.

NB2: Choice Cascade User-Owned does not really make sense for reparent and should behave like Cascade All.

A very important thing to remember about the Cascade in CRM is that it’s completely different from the CRM Security Role given to the user:

When you request access to an object in CRM, your role privileges are evaluated dynamically and applies on all CRM records in the Database, thus if you change your role definition in CRM, the changes take effect directly and applies for already created records.

Rights given via Cascade are written in the Database without any possibility to easily remove them, plus, if you change the cascading options, the new settings will apply only for record created after the Change……

(**) PrincipalObjectAccess table in MSCRM Database.

Regards

Benjamin