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

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:

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

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:

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

The record shows up:

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

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:

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

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:

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

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.