No Results
Search Tips:
- Please consider misspellings
- Try different search keywords
Newer Version Available
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.