Role based sharing - unique names per team needed?

Question

An example such as this Trailhead one:

has distinct role names everywhere and so it is easy to understand the statement:

Users at any given role level can view, edit, and report on all data owned by or shared with users below them in the role hierarchy

But what happens if the role names repeat e.g. there are 4 "VP Development" people with the 4 teams below them in the tree using the same roles names? Given that there is e.g. nothing that identifies which "Director Product Management" reports to which "VP Development", each "VP Development" can see all the records of all the teams?

So presumably all the the role names need to to be unique to each team to keep the records private?

Answer 1

Correct. If the goal is to hide records between Director Product Management teams then you would need to create distinct trees in the reporting hierarchy so that VP Development 1 has only his team's roles reporting to him/her.

           VP Dev 1                                 VP Dev 2
             |                                         |
             |                                         |
Dir Prod 1   |     Dir Prod 2              Dir Prod 3  |   Dir Prod 4

This works together with how your data will be used (ex. who will own what records) and whether any of these teams will have different profiles/perm sets/permissions in terms of object access.

So presumably all the the role names need to to be unique to each team to keep the records private?

Technically, no. You could disable Grant Access Using Hierarchies within the org-wide sharing defaults screen for a given object (and use private model). From there you have some options

1. You could create sharing rules for each object based on criteria of the records (values within it) or based on who owns it.
2. You could have owners of the record manually share their records with their team/users. This probably depends on your use case (how large the teams are, how many objects follow your pattern above) for it to be reasonably feasible.

An important point with doing the above is whether you'd like to use out of the box filters on reports/list views ("my teams") which depend on the role hierarchy.

Answer 2

The role hierarchy doesn't work off of names, it works off of id values. There is something that identifies which role reports to which, namely the ParentRoleId. As such, you could build the roles as:

• VP Development
  • Director Product Management
    • Product Development Team
  • Director Product Management
    • Product Development Team
  • Director Product Management
    • Product Development Team
  • Director Product Management
    • Product Development Team

The difficult part is making sure you assign the correct users to the correct role. This is usually easier done with an API tool, but it is possible to do so in the UI as well.

Having different role names is really meant to be a tool for administrators to keep the roles straight in the UI (especially when setting up a new user), but you can also use the Assign feature in the Roles view in Setup to make sure the user is in the correct role after creation.