Record Ownership and Assignment

“Out of the Box” Behavior when Records are Reassigned

By default, Dynamics CRM does a lot more than people generally realize when records are reassigned. For example, if you reassign an account record from one CRM user A to user B, the default behavior is for all child records of the reassigned account to also be reassigned to user B. This might seem reasonable at first, but when you realize it applies to every one of the following record types regardless of its status, it can seem a little alarming:

Suppose you use some combination of the sales process records (Opportunity->Quote->Order->Invoice) for historical sales reporting. If you do, and you’re relying on Dynamics CRM’s “out of the box” relationship behavior, reassigning an account record will definitely impact your historical sales reporting, essentially “reassigning” everything from won opportunity records to paid invoices to whoever the account was reassigned to!

Fortunately, there’s a relatively easy fix for this. The fix is easy enough…but in my experience it’s often made only after the problem is discovered. I’ve had plenty of clients who didn’t realize this for some time, and wondered why their historical sales reports were always changing. (These were clients I started working with after they’d already implemented and been working with CRM for a while, by the way!)

The Problem with Reassigning Records

First of all, what do we mean by “reassigning” records? In CRM-speak, I’m talking about changing the value of the “Owner” field (a so-called lookup attribute). Here’s what it looks like on a standard account form:

Selecting a different value for the “Owner” field in this case would reassign the account to the newly selected CRM user. Along with a lot of other records, which is the potential problem. Assuming you’ve got sufficient security privileges, you can see the problem by following these steps:

1. Click Settings, Customization, Customize Entities.
2. Double-click Account from the list and the Account entity’s customization form will open.
3. Click 1:N Relationships in the Details area, and you will see something like this:

   

    

   This looks alarmingly confusing the first time you see it, and in my case, it wasn’t just the first time! This is the complete list of all of the 1:N relationships the Account entity has with other Dynamics CRM entities, and one of the great things about Dynamics CRM is how you can customize these relationships.

    

4. I think the best way to develop some intuition is to sort this list by the “Type of Behavior” column – just click on the column heading, and you’ll see something like this:

   

    

   Notice the “Type of Behavior” for the relationships that appear first in this sort is “Parental”. The reason I like this view is that these happen to be the out of the box relationships that make all of that reassigning happen, and they also happen to be the only relationships you can customize. (If you scroll down past these you’ll see System relationships, none of which you can change.)

    

The Fix

Now that we know where the problem lies, how do we fix it? To keep this article reasonably short, I’ll go through an example for the 1:N relationship from Account to Invoice. The steps will be identical for any other relationship, although business requirements might dictate different specific settings you’d make.

1. Double-click the line with “Invoice” as the Related Entity. You’ll see the Relationship dialog for the Account to Invoice 1:N relationship:

   

    

2. What you need to do here is change the default “Parental” relationship to “Configurable Cascading”. Pull down the “Type of Behavior” menu — the screen-shot shows me in the process of making the change. After making the change the dialog changes and the fields in the Relationship Behavior section are now selectable, as you can see here:

    

   

    

   Now you can see why the out of the box reassignment is so frisky: “Cascade All” means in this case that when the parent record (Account) is assigned (or re-assigned), the change cascades down to all child records (in this case, Invoice records attached to the Account). Depending on your business requirements, Cascade Active or Cascade None might be appropriate. I use Cascade Active for my organization, which essentially means that the new Owner of the account record will cascade down only to invoice records with a status of “active” – that is, completed or paid invoices will not get reassigned, which was the problem I was trying to fix.

3. Select Cascade Active, then click Save and Close to close the Relationship Behavior dialog.
4. Then click Save and Close again to close the customization form.
5. Finally, publish the changes by selecting Account in the entity list and clicking Publish.

That’s pretty much it. You’ll need to go through the same process for any of the other 1:N relationships you want to change; in my experience the most important ones to start with are probably the sales process entities I mentioned above.

Also, the same issues apply to custom entities you create: they can have 1:N or N:1 relationships to out of the box entities like Account, and while the default settings for those relationships may be fine…they may not be fine too. When it comes to custom entities you have more options. I’ll discuss those in a separate article, but in the meantime here’s a quick summary (if you need to do this you’ll see what I mean):

• A Parental relationship is the most restrictive. As you saw here, we started with Parental from Account to Invoice, which meant that every change to the parent record cascades down to the child records.
• Referential is the least restrictive, and nothing cascades down.
• Configurable Cascading is the most flexible…and the one you have to think about the most!