173 securing and sharing data when you first start

173
Securing and Sharing Data

When you first start defining a role hierarchy, the tree view displays a single placeholder node
with the name of your organization. From this point, we need to add the name of the role that
is highest up in the hierarchy — in our case, the CEO.
Note: If you're building your Recruiting app with a free Developer Edition
organization, you may have a role hierarchy predefined as a sample. That's alright.
You can still follow along and create some more roles.
2. Just under Universal Containers, click Add Role .
Note: If the CEO role already exists, click Edit .
3. In the
Label
text box, enter
CEO
. The
Role Name
text box autopopulates with
CEO.
4. In the
This role reports to
text box, click the lookup icon and click Select
next to the name of your organization.
By choosing the name of the organization in the
This role reports to
text box, we're
indicating that the CEO role is a top-level position in our role hierarchy and doesn't report to
anyone.
5. In the
Role Name as displayed on reports
text box, enter
CEO
. This text
is used in reports to indicate the name of a role. Since you may not want a long role
name, like Vice President of Product Development, taking up too much space in
your report columns, it's advisable to use a shortened, yet easily identifiable,
abbreviation.
6. Leave any other options, such as
Opportunity Access
, set to their defaults. These
access options don't have anything to do with our Recruiting app, and only appear
if you have the org-wide defaults for a standard object set to a level more restrictive
than Public Read/Write.
7. Click Save .
174
Chapter 7: Securing and Sharing Data

Figure 62: CEO Role Detail Page
Now that we've created our first role, we can assign the appropriate user to it.
8. Click CEO to open the CEO role detail page.
9. In the CEO role detail page, click Assign Users to Role .
10. In the
Available Users
drop-down list, select All Unassigned.
11. Choose a user from the list (in our case, Cynthia Capobianco), and click Add to
move her to the
Selected Users for CEO
list.
12. Click Save .
If we return to the main Roles page from Setup by clicking Manage Users > Roles , we can
now see our new CEO role in the hierarchy.
Note: If you see the Sample Role Hierarchy image, click Set Up Roles .
13. Define the rest of the roles according to the Universal Containers Role Hierarchy
diagram.

role reports to
text box is automatically filled in with the name of the appropriate
role.
Not too hard, right? With org-wide defaults and a role hierarchy in place, we're actually pretty
close to finishing up our record-level access permissions. All we have left to do is share
recruiting-related records between groups that appear in separate branches of the role hierarchy,
and between peers in a single group. Fortunately, we can accomplish both of those tasks with
a combination of sharing rules and manual sharing. We just need to figure out what's left that
needs to be shared, and with whom.
What's Left to be Shared?
So what is left to be shared? After reviewing our table of required permissions, it turns out it's
just a few more things (remember, since users always have access to the records that they own,
we need to worry only about the read and update permissions for our record-level access
settings):
•
Recruiters need read and update access on every position, candidate, job application, and
review record that exists in the app.
•
Hiring managers need:
◊ Read and update access on position and job posting records on which they're the hiring
manager
◊ Read access on candidate records for which they're the hiring manager
◊ Read and update access on every job application and review record
•
Interviewers need read access on the candidate and job application records for people they're
interviewing, and the ability to update their reviews.
That shouldn't be too hard! Let's go do it.
Introducing Sharing Rules
First let's see what we can do with sharing rules. Sharing rules let us make automatic exceptions
to organization-wide defaults for particular groups of users. We've already defined several