When we have a Customer Account in CRM, this will typically be owned by a particular Salesperson who will be responsible for managing the relationship with this Account.
This relationship may consist of different Contacts, Opportunities, Orders or Service Cases – and the Salesperson (or Account Manager at this point) may be responsible for all of them.
But what happens when the Account needs to be reassigned? Say, if the Salesperson moves to a different Sector or Region, or potentially leaves the company altogether.

So, what happens next.. ?
Do we need to reassign not only the Account, but all the individual Opportunities and Orders as well?
Fortunately not, Dynamics CRM gets round this using Cascading Rules, where we define a Rule in CRM that stipulates:
- If the Customer Account is reassigned, then all the related Opportunities are also reassigned to the new Owner.
- Or in a similar vein, if the Customer Account is deleted, then all the related Opportunities are also Deleted. (not recommended! But illustrates the point of doing something with the related record when the parent changes)
This is done by reviewing the Customisation Screen for the Relationship in CRM:

Here we can see the area for ‘Relationship Behaviour’ that allows us to define what happens to the Child Records in this Relationship when the Parent Record is changed.
In the above example, we are looking at the relationship between the Parent Company and the related Child Opportunities – and so we are defining what happens to the Opportunities for that Company when the Company is either:
- The Company is assigned to a New Owner
- The Company is Shared with another User
- The Company is Unshared with another User
- An Opportunity is Reparented from the Company to another Company
- The Company is Deleted from CRM
- The Company is Merged with another Company
These 6 events are each configurable to give the Cascading Rules in CRM – and so allow us to define what happens when managing the Company between different Salespeople.
This can seem quite straight forward but is a key area for defining CRM to work for different Organisations – as if we take the following scenarios we can see how these Rules may need to be configured:
- The Account Manager is solely responsible for all New Business or Existing Business Opportunities with a Customer
- Assign should likely be Cascade All, so all Opportunities are reassigned to a new Account Manager
- However, we may want to retain historical Opportunities under the original Account Manager for Audit – if so then Assign should be Cascade Active, so only active Opportunities are reassigned to the new Account Manager
- The Account Manager is generally responsible for the Customer but has several other Sector Salespeople working on Opportunities within the Account
- Assign should likely be Cascade User-Owned, so some Opportunities are reassigned to a new Account Manager, but not the Sector Salespeople Opportunities
- The Account Manager may wish to share the Account with other people in the Organisation, but they should not see or be shared on existing Opportunities within the Account
- Share and Unshare should likely be Cascade None, so Opportunities are not automatically shared when the Account is shared
These examples show when these rules might be useful in practise and when considering Customer Accounts and Opportunities, these can be easy to follow.
However the tricky part of this logic comes into play when considering Activities – where we need to define this logic to Reassign, Shared or do not Reassign Activities for a Customer or Opportunity when that Customer or Opportunity is reassigned but if we think this through:
- The Account is Reassigned – The Customer Account is assigned to a new Owner
- What happens to the Opportunities? Depending on the Rule between the Opportunities and the Account, this will either Reassign All, Reassign Active, Reassign User-Owned or Assign None
- What happens to the Activities for each Opportunity? For each Opportunity reassigned, there may be Activities regarding that Opportunity
- Depending on the Rules between these Activities and the Opportunity, this will either reassign All these Activities to the New Owner, reassign Only Active Activities, reassign only those User-Owned by the previous owner, or reassign None.
- What happens to the Activities for each Opportunity? For each Opportunity reassigned, there may be Activities regarding that Opportunity
- What happens to the Activities for the Account? There may also be Activities regarding that Customer Account
- This will either reassign All these Activities to the New Owner, reassign Only Active Activities, reassign only those User-Owned by the previous owner, or reassign None.
- What happens to the Opportunities? Depending on the Rule between the Opportunities and the Account, this will either Reassign All, Reassign Active, Reassign User-Owned or Assign None
And so on for other relationships that the Customer Account may have for Contacts, Orders or Service Cases.
Typically many Organisations will want any Activities to move to the new Owner if the Owner is changed – but this is a key part of CRM to define when designing the architecture for a new CRM Solution.
When looking at this architecture, the following points are worth bearing in mind:
- Ownership of Records is Key – who owns an Account or Opportunity can drive their daily diary of activity, and can form the basis of their Bonus or KPIs
- Sharing is Invisible – who is shared on a record is generally managed ‘behind-the-scenes’ in CRM and so is difficult to unpick if it goes wrong and can lead to a ‘everyone sees a different view and no one is quite sure why’ view of the CRM which is damaging for User Adoption.
- Prevention is better than Cure – if the Ownership of Opportunities and Activities goes astray, it can take long series of Manual Bulk Updates or Bulk Running Workflow to fix and it is alot easier to have this mapped out in advance than fixing after the event!
So this area of CRM can easily be forgotten in some projects, particularly where large chunks of Custom Development or Integration might be taking the limelight, but it can be crucial to a successful solution and only takes a few moments to design, customise and crucially test when mapping out the building blocks of how CRM will work for an Organisation.
Further Reading
Cascading Rules are part of the ‘old engine room’ of Dynamics CRM and so have been around for a while – and so the following articles and descriptions may provide further information on the topic:
MSDN – Entity Relationship Behaviour
Implications of Cascading Ownership
https://joegilldotcom.blogspot.co.uk/2015/03/the-implications-of-cascading-ownership.html
Check and Set Assign Cascade Relationship Behaviour for Microsoft CRM
(includes screens from CRM 3.0 to give a feel for how far back this goes!)
Cascading Rules in Microsoft Dynamics CRM
https://www.magnetismsolutions.com/blog/11-06-22/Cascading_Rules_in_Microsoft_Dynamics_CRM.aspx
