*** NOTE: ALL INFORMATION IS ACCURATE AT DATE OF PUBLISHING ***
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:
Checking User Access To Model-driven Apps (D365 CE)
This is just 1 of 338 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.