Hands up if you have ever reassigned a case to a user and had all related activities be reassigned along with it? Or, worse, reassigned an Account and had all related cases be reassigned too? If you haven’t, phew! It’s very frustrating and a PITA to unpick and sort through to fix. If you have, and figured out how to fix it, cool. 🙂 However, it can be something that gets forgotten about, so I thought it was worth a quick article explaining why it happens, and how to prevent it. It’s all to do with Configurable Cascading.

First let’s start by looking at the Account entity. Open up the main solution and then open the 1:N Relationships. If your organisation manages cases, this is probably a good one to start with. Sort by Related Entity and find the Case. Open up the relationship.

Scroll down to the Relationship Behaviour (or Behavior!) section. You’ll notice that it’s set to Parental by default. What this is showing us is that if the Account is Assigned, all of the cases for that Account will be reassigned to the new Account owner. In most organisations with a Customer Services or Support team, the owner of the Account record is highly unlikely to be working through and managing cases. The good news is, we can change that.

Instead of Parental, we will change it to Configurable Cascading. This then allows us to edit each of the individual sections as desired.

We have 4 options:

  • Cascade All – this is the default option, and means all related records (Active & Inactive) would be reassigned.
  • Cascade Active – reassign all active records to the new Owner of the Account
  • Cascade User-Owned – only change records that are owned by the same user
  • Cascade None – don’t change any of the case records (or entity you are modifying)

So, we will change the Assign behaviour to Cascade None. Then save and publish the entity.

This will save you a MASSIVE HEADACHE! So if you haven’t already done this, or aren’t sure, just take a quick look and check the relationship behaviour for some of the entities in your instance. Cases is just one to review, here are a few others to check on that might save you a lot of time in the future:

  • Accounts – check the relationship to Appointments, Emails, Phone Calls, Tasks, Opportunities, Cases, Contacts (unless you want the Owner of the Account to also own the Contacts)
  •  Contacts – check the relationship to Appointments, Emails, Phone Calls, Tasks, Opportunities, Cases
  • Cases – check the relationship to Appointments, Emails, Phone Calls, Tasks
  • Opportunities – check the relationship to Appointments, Emails, Phone Calls, Tasks

I’m sure there are others you can think of, but you get the idea. Hope this helps someone and saves them time!

Check out the latest post:
Predefined Placeholder Access In Customer Insights - Journeys

This is just 1 of 456 articles. You can browse through all of them by going to the main blog page, or navigate through different categories to find more content you are interested in. You can also subscribe and get new blog posts emailed to you directly.

6 thoughts on “Configurable Cascading – Prevent Auto Reassign Of Records

  1. I’m on D365 and the Type of Behavior in the relationship I’m looking at is set to “System”, all relationship behaviors are read only. The Assign is set to Cascade All and it’s been brought up that this may need to change since inactive/Won records are being reassigned.
    Do you know how I can go about changing this?
    Thank you!

    1. Hi Lindsay, are you referring to the Opportunities being reassigned when you reassign an Account? If so, go to the Account entity, then look at the 1:N relationships and find the Account to Opportunity. From the Relationship Behavior section you can change the type of behavior to Configurable Cascading and change the options for Assign/Share/Unshare/Reparent to Cascade Active or Cascade None depending on your specific requirements.

  2. Hi,
    With our deployment the type of behavior gets reset to Referential from Configurable Cascading on its own due to some unknown reasons every few weeks. And all the task, calls and opportunities ownership get assigned to contact owner.
    Has someone experienced this type of issue?

    1. Hi Rahul. That’s really strange for it to reset itself. If you haven’t already, I would open up a support ticket with Microsoft about this to get them to look in to the issue.

  3. Hi,
    can this cascading setting be changed beyond disabling it?
    We have our custom field “Technical Account Manager” on the Account entity and we would like to reassign cases to the TAMs instead of the AMs (which is the “Owner” field on the Account entity).

    I think a Flow running on change of “TAM” to update all cases to the new assigned TAM should work, but maybe there is another way using the cascading settings of relationships?
    I guess not, as it probably only works on the “real” owner field?


    1. Hi Serf. For this, I would recommend using Power Automate. The Cascading rules are based on the record Owner rather than any custom field. So yes, creating a flow is the option I would go for.

Comments are closed for this post.