CRM 2011 Parental Relationship Behaviour (the Reparent action) in Practise

Parental relationships in Mscrm do a couple of things, in this post I’m going to focus on the reparent action.

(As a side note, reparent isn’t exclusively used in the parental behaviour, but is where it is most commonly used).

The MSDN gives a pretty decent description of the reparent action.

The reparent action is very similar to the share action except that it deals with the inherited read access rights instead of explicit read access rights.

For example, there is a parental relationship between Opportunity and Account based on the CustomerId referencing attribute. If you are the owner of an account and there is an opportunity associated with that account, you inherit read access rights to that opportunity and any records associated with it.

However I always find it easier to understand with a practical example. So take the following setup.

We have three business units; Gold, Silver and Bronze, three users; Georgia, James and Sarah in those business units. We have two records, a Case – owned by James – and a Task – owned by Sarah. The task is regarding the case, the relationship between those entities is parental, reparent is set to ‘Cascade All’.

All users have the same security role which grants them permissions to read and write on all cases across in their business unit and child business units, but only read and write on activities (task) within their business unit.

So in practise this means:

  • Sarah can:
    • Write and edit the task.
    • Cannot write or edit the case – reparent is one way, from primary (case) to related (task). (Note: Sarah can see the name of the case via the regarding field on the task, but if she tries to open it she will receive an error).
  • James can:
    • Write and edit the case.
    • Write and edit the task – even though it is outside of his business unit and the permissions granted to him via his security role. Reparent grants the permissions on the task record which are specified in the security role, e.g. James cannot delete the task.
  • Georgia can:
    • Write and edit the case.
    • Cannot see, write or edit the task – reparent is only applied to the owner of record (the case).
Advertisements

5 thoughts on “CRM 2011 Parental Relationship Behaviour (the Reparent action) in Practise

  1. Great article, filling in a gap in lots of people’s understanding of this (to the extent that most people I come across have no idea what this behaviour setting does at all).
    The way I tend to describe this is that if you own the parent record, you can act on the child record (for which the “Reparent” behaviour is set to cascade) as if you owned that record yourself. This means that your own normal security roles apply, so there is no possible confusion about which role takes effect etc.
    Your example is sound because it shows this working even across BUs, but even at a simpler level it still matters, with a single BU for example – I have seen many a forum question about this when someone has built what they think is a robust and secure model only to find it full of holes. For example, sales people given a role so they can only read and edit their own Opportunities, but they then realise that actually they can edit Opps belonging to other people. It takes a while to figure out that this is the default behaviour if Alice owns an Opp A which is for Customer B which is owned by Bob – as the Account Manager, Bob can see and edit the Opportunity as if it is his own, which seems to make sense for most scenarios.
    For the geeks that care, the privileges to these other records are written as records in the PrincipalObjectAccess table, which is also where shares are stored. In both cases they use a bit masked value to show the type of access allowed (read, write, delete etc). Parental implicit rights are distinct from explicit share rights, using different values in the bit mask.

    • hi! thanks for the article!
      There is the question for the Adam. You say that “the privileges to these other records are written as records in the PrincipalObjectAccess table”. If I am the owner of the parent record and also for all child records as well, do I inherit read rights for child records, so that it is written in the POV table? I ask it because it looks redundant – if I own child records I can read them as well an there is no logical reason to grant me (as an owner) such permissions to read these records.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s