Behavior Change in Cascading Assign for Microsoft Dynamics CRM 4.0 - Microsoft Dynamics CRM Team Blog - Site Home

The functionality in Cascading Assign has been changed in Microsoft Dynamics CRM 4.0, Update Rollup 8 or newer. As originally designed, only those objects meet the cascading rules can participate the cascading operation. For Cascading Assign, there are 4 rules:

Cascade All: all related objects can participate the cascading operation
Cascade User-Owned: only those related objects with the same owner as the parent’s can participate the cascading operation
Cascade Active: only those related objects in the active state can participate the cascading operation
Cascade None: no related objects can participate the cascading operation

When the primary object is to be assigned to the new owner, it will trigger the Cascading Assign to all the related objects in the cascading tree that meet the cascading rules. It will assign the new owner and revoke the inherited access right from the previous owner of the primary object (root) to all those objects.

This behavior (found in CRM version 4) has two issues regarding to the access rights inherited from the owner of the parent objects:

1. It only revokes the inherited access right from the previous owner of the primary object (root).

2. It only revokes the inherited access right to those related objects that meet the cascading rule.

Here are the user scenarios to illustrate the issues:

Scenario 1: Three objects created by different users.

The user U1 creates the account A
The user U2 creates the contact C
The user U3 creates the task T
Set A the parent customer to C
U1 is granted the inherited access right (IA1) to C via Reparent
Set C the regarding object to T
U1 & U2 are granted the inherited access rights (IA1 & IA2) to T via Reparent
Assign A the new owner U4

The result: All three objects are assigned to the new owner U4 and the inherited access right (IA1) from the previous owner of A (U1) are revoked for the child objects C and T. However, the inherited access right (IA2) from the previous owner of C (U2) is not revoked for T. Therefore, U2 still can access to T via IA2 after the Cascading Assign even though it is no longer the owner of C.

Scenario 2: Child object does not meet the cascading rule.

Set Account_Tasks relationship to Cascade All for Reparent, Cascade User-Owned for Assign (see the form below)
The user U1 creates the account A
The user U2 creates the task T
Set A the regarding object to T
U1 is granted the inherited access right (IA1) to T via Reparent
Assign A the new owner U3

The result: Because T has the different owner than A’s, the relationship with A does not meet the cascading rule (User-Owned). Therefore it is excluded from the Cascading Assign action. The inherited access right (IA1) from the previous owner of A (U1) stays and U1 still can access T via IA1 after the Cascading Assign even though it is no longer the owner of A.

New Behavior

With the CRM version 4 design change for Cascading Assign, all objects in the cascading tree will be collected and processed thusly:

(new) All related objects in the cascading tree are collected including those objects do not meet the cascading rules.
All related objects that meet the cascading rules will be assigned to the new owner of the primary object.
(new) The inherited access rights from all previous owners of the reassigned parent objects will be revoked except those are still shared with the parent objects.

Please note the cascading rule will be broken for the sub-tree if the specific object does not meet the cascading rule with its parent object. All objects in the sub-tree will be treated as no-cascading no matter if the individual object meets the rule with its parent or not.

More Information

This change is available in CRM 4.0 Update Rollup 8 or newer. You can download it as part of the newest CRM Update Rollup.

For the inherited access rights left in your CRM system from the previous Cascading Assign there is an optional tool for you to fix the inherited access rights to the objects in organization wide or the specific cascading tree let by the specific object. Here is the usage of the tool in the command line:

Microsoft.Crm.SE.FixPOAForCascadeAssign.exe <OrgName> [<ObjectId > <ObjectTypeCode>]

For example:

Microsoft.Crm.SE.FixPOAForCascadeAssign.exe AdventureWorksCycle Microsoft.Crm.SE.FixPOAForCascadeAssign.exe AdventureWorksCycle 21315527-0C71-DB11-8F1D-0017A41F0DE7 1

Cheers,

Chris Xia