Newer Version Available

This content describes an older version of this product. View Latest

Role Hierarchies in Our Recruiting App

Given the Universal Containers role hierarchy that's pictured in the Universal Containers Role Hierarchy image, let's think about how implementing this hierarchy will open up certain kinds of record-level permissions to various users of our Recruiting app. Remember, since defining our org-wide defaults, our hiring managers are currently allowed to only view all position, job posting, and employment website records, and to view and update other recruiting records that they own. That doesn't make our app all that useful. However, once we implement our role hierarchy, we'll automatically grant several kinds of record-level permissions to various users. For example:
  • The CEO, Cynthia Capobianco, will be able to view and update every record that anyone else in the organization can view and update.
  • The VP of Development, Andrew Goldberg, will be able to view and update any record that his managers or his managers' employees can view or update.
  • The VP of Human Resources, Megan Smith, will be able to view and update any record that Phil Katz, her recruiting manager, or Mario Ruiz, Phil's recruiter, can view and update.
  • The Recruiting Manager, Phil Katz, will be able to view and update any record that is owned by Mario Ruiz, his recruiter.
  • The Software Development manager, Ben Stuart, will be able to view and update any record that is owned by Melissa Lee, Tom Zales, or Craig Kingman, his software engineers.
  • The director of QA, Clark Kentman, will be able to view and update any record that is owned by Flash Stevenson or Harry Potterham, his QA Engineers.
  • The director of Product Management, Frank Linstrom, will be able to view and update any record that is owned by Amy Lojack or Andy Macrola, his product managers.
As we can see, the role hierarchy is very powerful in opening up data for people high up in the role hierarchy tree! However, let's look at some of the gaps that we still have in our record-level permissions:
  • Megan Smith (and her whole recruiting team) won't be able to view any reviews that are owned by members of Andrew Goldberg's Development team because she doesn't have a direct line down to any Development roles in the role hierarchy.
  • Ben Stuart, the software development manager, also won't be able to see any reviews that were written by members of the QA or Product Management groups, even if QA engineers or product managers interviewed candidates for a software engineering position in his group.
  • Melissa Lee, a software engineer, won't be able to see the records for candidates that she's supposed to interview.

Clearly we'll need to use other record-level sharing methods to open up data between peers in the same group, and also between groups that appear in different branches of the role hierarchy (we'll get to those later in this chapter). However, the role hierarchy does give us a good start toward opening up record access, so let's take a look now at how to define it.