MSCRM - Cascade Option on Relationships in Microsoft CRM
In MS CRM, an important relationship between the entities. The following I summarized and quoted from diff. sources to explain the relationships.Applied to CRM 2011
From : Benjamin
All the options mean:
Assign,Share,Reparent,Unshare and all the Cascade Choices
All,None,Active,UserOwned with simple examples.
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.
From : Frank
Scenario: What happens to the Account’s child records (Contacts, Opportunities, Activities, History, etc.) ownership if we reassigned the Account to another owner? If I have a CRM account record "ABC, Inc." with an initial ownership of "Owner2" and I then reassigned the "ABC, Inc." account record to "Owner3" – what effect does this have on the ABC, Inc.’s child records ownership?
Answer: Under the default Microsoft CRM setting - they will all be reassigned to "Owner3".
An important note is that for CRM History records (activities that are completed) or any other "completed" record types such as CRM Opportunities, Leads, Cases, etc. - we should keep the data intact and not change the Owner info since it should be considered "historical" data.
So, if this is not the desirable initial setting, how do we change it?
Answer: This setting can be updated under the "Relationship Behavior" section in the Account customization (CRM Client >> Settings >> Customization >> Account >> select the child record type under "Related Entity")
From : Armanino
We recently discovered an “undocumented feature” in the Microsoft Dynamics CRM 2011 security model that only affects users on teams that own records. The issue came up when a client called and said that his sales people were able to see other people’s opportunities when they shouldn’t. The Sales Person security role was defined to only allow these people see their own opportunities, but we were able to determine that they were seeing opportunities owned by others when the parent customer of that opportunity (Account or Contact) was owned by a team that this user was a part of.
After opening a ticket with Microsoft, we learned that this was “functioning as designed.” Although not documented anywhere, Microsoft Dynamics CRM permissions to child records are indeed inherited from parent records. The setting that drives this behavior is not documented but is configurable. On the relationship (in this case between Account and Opportunity), you must set the ‘Type of Behavior’ to ‘Configurable Cascading’ and both ‘Assign’ and ‘Reparent’ to ‘Cascade None.’
At this point, you have stopped CRM from inheriting of permissions for future child records, but for opportunities that already exist, there is still an entry (a non 0 value in the InheritedAccessRightsMask field) in the PrincipalObjectAccess (POA) table that says this record has inherited permissions from its original parent. They can still be seen by the wrong users and since we have stopped the cascading, changing the owner of the parent record from the team to a different user no longer has any effect on the child record.
The recommended way to reset this field is to simply “reparent” the CRM opportunity temporarily (for instance to a dummy account) and then set the parent customer back to its original. The idea is that by setting the customer field, the system reexamines the relationship, sees that it is no longer cascading and that permissions should not be inherited, this then resets the InheritedAccessRightsMask to 0.
Hopefully this is as far as you need to read as this will clean up such a security issue in a vanilla system. In our particular client situation however, it did not resolve the issue because we had created an extra relationship between Account and Opportunity (a second lookup to Account on the Opportunity form). This relationship could not be set to ‘Configurable Cascading’ because the system will not allow you to have two different relationships that define cascading rules on the same two entities. This second relationship seemed to interfere with the resetting of the inheritance field and this was accepted as a bug by Microsoft. We are not expecting a fix any time soon for Microsoft CRM 2011.
If you run into this, your remaining options are few. If you have an on-premise implementation of Microsoft CRM you have the option of manipulating the SQL database directly to set the InheritedAccessRightsMask in the PrincipalObjectAccess table to ‘0’ for the affected records. Note: Manipulating the database directly is completely unsupported and not recommended by Microsoft.
The only other option we can see is to remove the extra relationship and do the recommended cleanup described above. If you have data in that field, this will require some finagling to preserve it.
To avoid this scenario, when initially implementing Microsoft CRM in an environment where security needs to be tight and teams are going to own records, save yourself some trouble and turn off cascading from the start.
Reply from : woodsworkblog
This feature is documented, though I didnt know that once applied, changing the relationship didnt remove the effect. In the case of getting around being unable to set multiple ‘Configurable Cascading’ did you try setting a relationship temporarily to 'Referential', that doesnt use 'Reparent'.
I recently blogged about the Reparent Action here:
Documented on the MSDN here:
ReplyDeleteThanks for sharing a best informetion
CRM Development Dubai:ERP Development Dubai
Thanks for sharing the Valuable information
ReplyDeleteDynamics crm online training
Microsoft dynamics crm online training