“Share/Unshare” Relationship Behavior – something to keep in mind when working with the hierarchies of records

By | October 5, 2018

You might be creating a number of new entities, all related to each other through a hierarchy of relationships, and, then, you might have to set up security so that, if a user were given permissions to the top-most entity in that hierarchy, that user would also get access to the other entities.

Imagine, for example, that you had a Parent and a Child entities like this:

image

And the security permissions for regular users are set up like this:

image

image

So the users can do whatever they want with the records they own, but they can’t even see somebody else’s records. The record above was created using a system admin account, and here is how a user having only “user-owned” read permissions can’t see any of those:

image

So let’s say the system admin decides to share that parent record with the user:

image

The record shows up:

image

But there is still a problem – the user can’t see any of the child records:

image

Remember there were supposed to be two kids there?

And of course they would not show up since we only shared the parent record, so all the child records would have to be shared with the user separately.

Is there an easier way to do the same?

This is where “Share/Unshare” properties of the relationship behavior might be very useful. By default, you will get “Referential” behavior there which will look like this:

image

What if we change that to “Configurable Cascading” and update “Share/Unshare” to use “cascade all” instead so it looks like this:

image

Save, publish all.. Re-share the Parent record(may have to actually un-share, and, then, share).. ask the user to reload their “Parent” screen, and, lo and behold, those lost kids have just been found:

image

Most importantly, those Child records are not shared directly with the user:

image

It’s all taken care of through the relationship.

And why is that important? Because there are all sort of scenarios where this can come into play. For example, consider the access teams. You can create an access team template for the parent entity only, and, if the relationships are set up as described above, just by adding a user to the parent record’s access team, you will grant that user access to the whole hierarchy of records without having to do it individually on each of those records.

3 thoughts on ““Share/Unshare” Relationship Behavior – something to keep in mind when working with the hierarchies of records

  1. Lars Martin

    Be careful with using the “Cascade all” property. It can blow up your POA table dramatically.

    Reply
    1. Alex Shlega Post author

      I agree, but, in the absence of other security mechanisms(it’s either owning or sharing), we need to weigh pros and cons.. and, sometimes, the answer is straightforward since the requirements are coming from the regulations. For the POA, this post might offer some options(but not the ultimate solution): https://crmtipoftheday.com/969/the-problem-with-sharing/

      Reply

Leave a Reply to Alex Shlega Cancel reply

Your email address will not be published. Required fields are marked *