At times, within Dynamics CRM, you discover a button and get all excited that this function will be a simple fix for your need. This is how most people feel when trying to deactivate a CRM user and they find the [reassign records] button.
The initial delight that you feel when you think you can just reassign all one user’s records to another user, and then deactivate the user you no longer need, is often short lived.
Out of the box Dynamics CRM is too smart (in this case). If you
reassign an account record from CRM user A to user B, the out of
the box behaviour is for all child records of the reassigned
account to also be reassigned to user B. While this may seem
reasonable at first, you soon realise that this applies to all
record types regardless of status. For example, if you reassign an
account any related cases will also be moved (even if they are
closed). Scary!
If you use historical sales reporting then obviously all your
historic data is no longer correct.
Thankfully, there is a simple fix.
When we say "reassigning records" we are talking about changing
the value of the "owner" field within the CRM entity. If we change
the value of the "owner" field we are effectively reassigning the
record to a different CRM user (along with many other records,
which is where the issue lies). With the necessary 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 get
something like this:
This is the complete list of all of the 1:N (one to many)
relationships the Account entity has with other Dynamics CRM
entities. The great thing about Dynamics CRM is that we can
customize these relationships.
4. If you sort this list by the "Type of Behaviour" column -
just click on the column heading, and you'll see something like
this:
Notice the "Type of Behaviour" for the relationships that appear
first in this sort is "Parental". This view is great because these
are 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.)
So how do we fix it?
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 "Type of Behaviour"
default "Parental" relationship to "Configurable Cascading". The
below screen-shot shows me in the process of making the change.
After making the change the dialog changes and the fields in the
Relationship Behaviour section are now selectable, as you can see
below:
Now you can see why the out of the box reassignment is so
excitable: "Cascade All" means in this case that when the parent
record (Account) is 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 like to use Cascade Active,
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.
3. Select Cascade Active, then click Save and Close to close the
Relationship Behaviour 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 it really. 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, and support if you need
to look at historic reporting on your support team's workload,
etc..
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 or Contact, and while the default settings for those
relationships may be ok…they may not be ok too. When it comes to
custom entities you have more options. Here is 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!
Trust this makes your life much easier when an employee leaves
and you can now keep your historic reporting data intact.