Chapter 7: Securing and Sharing Data

Controlling Access to Data in Our App

As we've already seen, there are three types of users who will need to access the data in our
Recruiting app: recruiters, hiring managers, and interviewers. To these three, let's add a fourth
type of user—a standard employee who doesn't perform any interviews and who never needs
to hire anyone. (This employee will help us determine the default permissions that should
apply to all of the new recruiting objects in our app.)

One by one, let's take a look at the kinds of access that each one of these users needs and, more
importantly, the kinds of access they don't need to do their jobs. Once we've compiled a set of
required permissions, we'll figure out how to implement them in the rest of the chapter.

Required Permissions for the Recruiter

For our first set of required permissions, let's take a look at Mario Ruiz, a recruiter at Universal
Containers. To do his job, Mario needs to be able to create, view, and modify any position,
candidate, job application, or review that's in the system, and have full control over job postings
on employment websites. Likewise, Mario needs to view and modify the recruiting records
that all of the other recruiters own, since all of the recruiters at Universal Containers work
together to fill every position, regardless of who created it.

Although Mario has the most powerful role in our Recruiting app, we still can't give him
complete free reign. While it's OK for job posting and employment website data to be
permanently deleted at any time, state and federal public records laws require that all other
recruitment-related records be saved for a number of years so that if a hiring decision is
questioned, it can be defended in court. Consequently, we need to make sure that Mario will
never accidentally delete a record that needs to be saved to fulfill the law.

But how will he keep the number of positions, candidates, job applications, and reviews in
check if he can't delete them? Won't the app become swamped with old data? Not if we're
smart about it—instead of having Mario delete old records, we can use the Status field on
a record as an indication of whether it's current. We'll filter out all of the old records by using
a simple list view.

Here's a summary of the required permissions that we need to implement for a recruiter:

130
 Securing and Sharing Data

Table 21: Summary of Required Permissions: Recruiter

Position Candidate Job Review Job Posting Employment

Application Website
Recruiter • Read • Read • Read • Read • Read • Read
• Create • Create • Create • Create • Create • Create
• Edit • Edit • Edit • Edit • Edit • Edit
• Delete • Delete

Required Permissions for the Hiring Manager

Our next set of required permissions is more challenging. Ben Stuart, our hiring manager,
needs to be able to access the recruiting records related to his open positions, but he shouldn't
be mucking around with other recruiting records (unless they're owned by other hiring managers
who report to him). Also, there are certain sensitive fields that he has no need to see, like the
social security number field. Let's go object by object to really drill down on what Ben does
and doesn't need to access in order to perform his job:
Position
First of all, Ben likes to post his own positions so that he can publicize
them as fast as possible, but in our app, Mario the recruiter ultimately
needs to take ownership of the record to make sure the position gets filled.
As a result, Ben needs the ability to create positions, but then we'll need
to find a mechanism to make sure that they ultimately get transferred to
Mario for ownership. (Hint: as you'll see in Using Custom Workflow and
Approval Processes on page 195, we'll tackle that problem with a workflow
rule that transfers position ownership to a recruiter when a new position
is created by a hiring manager. For now just assume that this already
works.)
Ben should also be able to update and view all fields for positions for which
he's the hiring manager, but he should only be able to view other managers'
positions.
Candidate
Ben sometimes wants to poach a prime candidate who's applying for a
position under another manager, but this is a practice that Universal
Containers frowns upon. As a result, Ben should only be able to view
those candidates who have applied for a position on which he's the hiring

131
Chapter 7: Securing and Sharing Data

manager. Also, since Ben has no reason to see a candidate's social security
number, this field should be restricted from his view.
Job Application
As the hiring manager, Ben needs to be able to update the status of those
job applications to specify which candidates should be selected or rejected.
However, he should not be able to change the candidate listed on the job
application, nor the position to which the candidate is applying, so we'll
have to find a way of preventing Ben from updating the lookup fields on
job applications.
Review
To make a decision about the candidates who are applying, Ben needs to
see the reviews posted by the interviewers, as well as make comments on
them if he thinks the interviewer was being too biased in his or her review.
Likewise, Ben needs to be able to create reviews so that he can remember
his own impressions of the candidates he interviews.
Job Posting
Ben wants to make sure his harder-to-fill positions are visible to the most
talented people in the field. The most efficient way to do this is by posting
open positions on various employment websites. Given that employment
websites have different types of users with varying skill sets, we should
give Ben the power to unilaterally create job postings on employment
websites, since Ben is the best person to ascertain which skill sets are
necessary for his open positions.
Employment Website
If Ben had his way, he would usurp all of the company's budget for posting
his open positions on employment websites; therefore, Ben shouldn't be
allowed to modify employment website records, as that would let him
redefine the company's budget for posting jobs and could lead to an
accounting fiasco. Still, we need to make sure that Ben can view
employment website records to get an idea of the employment websites
with which Universal Containers has accounts, and how much of the
budget for that employment website is available.

Here's a summary of the required permissions we need to implement for a hiring manager:

132
 Securing and Sharing Data

Table 22: Summary of Required Permissions: Hiring Manager

Position Candidate Job Review Job Posting Employment

Application Website
Hiring • Read • Read* • Read • Read • Read* • Read
Manager • Create (No • Edit • Create • Create*
• Edit* SSN) (No • Edit • Edit*
lookup
fields)

* Only for those records that are associated with a position to which the hiring manager has
been assigned

Required Permissions for the Interviewer

For our third set of required permissions, let's take a look at Melissa Lee's role as an interviewer.
Ben, her manager, likes Melissa to interview candidates for highly technical positions, but
doesn't want her speaking with folks who are applying for roles on the user interface team. As
a result, Melissa should be able to view only the candidates and job applications to which she's
assigned as an interviewer. No such restriction needs to exist on the positions that are out there,
but she shouldn't be able to view the minimum and maximum salary values for any of them.
Likewise, she shouldn't see the social security number of any candidate, since it's sensitive
information that has nothing to do with her job.

Melissa must be able to create and edit her reviews so that she can record her comments about
each candidate, but she shouldn't be able to see the reviews of other interviewers—reading
them might sway her opinion one way or the other. As with hiring managers and recruiters,
Melissa also shouldn't be allowed to delete any records to ensure that public records laws are
fulfilled.

Finally, the posting of jobs to employment websites has no bearing on Melissa's responsibilities,
so both the employment website and job posting records should be completely off-limits to
her.

Here's a summary of the required permissions we need to implement for an interviewer:

133
Chapter 7: Securing and Sharing Data

Table 23: Summary of Required Permissions: Interviewer

Position Candidate Job Review Job Posting Employment

Application Website
Interviewer • Read • Read* • Read* • Read** - -
(No (No • Create
min/max SSN) • Edit**
pay)

* Only for those records that are associated with a position to which the interviewer has been
assigned

** Only for those records that the interviewer owns

Required Permissions for the Standard Employee

Employees, such as Manny Damon on the Western Sales Team, are often the best resources
for recruiting new hires, even if they are not active hiring managers or interviewers. For this
reason, we need to make sure that employees like Manny can view open positions, but that
they can't see the values for the positions' minimum and maximum salary fields—otherwise
they might tip off friends to negotiate for a position's maximum salary value! Manny also
shouldn't be able to view any other records in our Recruiting app.

Here's a summary of the required permissions we need to implement for a standard employee:

Table 24: Summary of Required Permissions: Standard Employee

Position Candidate Job Review Job Posting Employment

Application Website
Standard • Read - - - - -
Employee (No
min/max
pay)

134
 Securing and Sharing Data

So Where Are We Now?

Now that we've gone through the required permissions for each of our four users, let's organize
our thoughts by summarizing them in the following table. In the rest of this chapter, we'll
figure out how we can use the platform to implement these rules in our Recruiting app.

Table 25: Summary of Required Permissions

Position Candidate Job Review Job Posting Employment

Application Website
Recruiter • Read • Read • Read • Read • Read • Read
• Create • Create • Create • Create • Create • Create
• Edit • Edit • Edit • Edit • Edit • Edit
• Delete • Delete

Hiring • Read • Read* • Read • Read • Read* • Read

Manager • Create (No • Edit • Create • Create*
• Edit* SSN) (No • Edit • Edit*
lookup
fields)

Interviewer • Read • Read* • Read* • Read** - -

(No (No • Create
min/max SSN) • Edit**
pay)

Standard • Read - - - - -
Employee (No
min/max
pay)

* Only for those records that are associated with a position to which the hiring
manager/interviewer has been assigned

** Only for those records that the interviewer owns

Tip: When implementing the security and sharing rules for your own organization,
it's often useful to create a required permissions table like this to organize your thoughts
and make sure you don't forget to restrict or grant access to a particular user. You'll
135
Chapter 7: Securing and Sharing Data

see that we're going to refer back to this table again and again as we go through this
chapter.

Data Access Concepts

Before we get started implementing our security and sharing rules, let's quickly take a look at
all the ways that we can control data on the platform:
Object-Level Security
The bluntest way that we can control data is by preventing a user from
seeing, creating, editing, or deleting any instance of a particular type of
object, like a position or review. Object-level access allows us to hide whole
tabs and objects from particular users, so that they don't even know that
type of data exists.
On the platform, we set object-level access rules with object permissions
on user profiles. We'll learn more about profiles in a little bit.
Field-Level Security
A variation on object-level access is field-level access, in which a user can
be prevented from seeing, editing, and/or deleting the value for a particular
field on an object. Field-level access allows us to hide sensitive information
like the maximum salary for a position or a candidate's social security
number without having to hide the whole object.
On the platform, we set field-level access rules with the field-level security.
We'll also learn more about that shortly.
Record-Level Security
To control data with a little more finesse, we can allow particular users to
view an object, but then restrict the individual object records that they're
allowed to see. For example, record-level access allows an interviewer like
Melissa Lee to see and edit her own reviews, without exposing the reviews
of everyone else on her team.
On the platform, we actually have four ways of setting record-level access
rules:

• Organization-wide defaults allow us to specify the baseline level of

access that a user has in your organization. For example, we can make
it so that any user can see any record of a particular object to which
their user profile gives them access, but so that they'll need extra
permissions to actually edit one.
• Role hierarchies allow us to make sure that a manager will always have
access to the same records as his or her subordinates.
136
 Securing and Sharing Data

• Sharing rules allow us to make automatic exceptions to

organization-wide defaults for particular groups of users.
• Manual sharing allows record owners to give read and edit permissions
to folks who might not have access to the record any other way.

Figure 45: Controlling Data with the Force.com Platform

The combination of all of these sharing and security settings in the platform means that we
can easily specify user permissions for an organization of thousands of users without having to
manually configure the permissions for each individual. Pretty neat! Now let's get started
learning more about each of these methods for controlling data, and actually implementing
the security and sharing rules for our app.

137
Chapter 7: Securing and Sharing Data

Controlling Access to Objects

First let's configure access to our Recruiting app custom objects. As we mentioned previously,
we can control whether a user knows that a particular object exists in the app by modifying his
or her profile. But exactly what is a profile, and what does it control?

Introducing Profiles
A profile is a collection of settings and permissions that determine what a user can do in the
platform, kind of like a group in a Windows network, where all of the members of the group
have the same folder permissions and access to the same software. Profiles control:

• The objects the user can view, create, edit, and delete
• The object fields the user can view and edit (more on that later!)
• The tabs the user can view in the app
• The standard and custom apps the user can access
• The page layouts a user sees
• The record types available to the user
• The hours during which the user can log in to the app
• The IP addresses from which the user can log in to the app

Profiles are typically defined by a user's job function (for example, system administrator or
sales representative), but you can have profiles for anything that makes sense for your
organization. A profile can be assigned to many users, but a user can be assigned to only one
profile at a time.

Standard Profiles
The platform provides the following set of standard profiles in every organization:

• Read Only
• Standard User
• Marketing User
• Contract Manager
• Solution Manager
• System Administrator

138
 Securing and Sharing Data

Each of these standard profiles includes a default set of permissions for all of the standard
objects available on the platform. For example, users assigned to the Standard User profile can
never create, edit, or delete a campaign.

When a custom object is created, most profiles (except those with “Modify All Data”) don't
get access to the object. You can find more detailed descriptions of all the standard profiles in
the online help, but the important thing to know is that you can never actually edit the
permissions on a standard profile. Instead, if you have access to the Enterprise, Unlimited, or
Developer Editions of the platform, you can make a copy of a standard profile and then
customize that copy to better fit the needs of your organization. That's what we're going to
end up doing for our Recruiting app (and as a result, Enterprise, Unlimited, and Developer
Editions will be the only editions that the Recruiting app will support).

Custom Profiles in Our Recruiting App

For our app, we've talked about four types of users: recruiters, hiring managers, interviewers,
and standard employees. We might just jump the gun and say that this equals four different
user profiles, but let's take a closer look.

Recruiters are pretty straightforward—they definitely represent a particular job function, and
they need access to different types of data than other users. They need their own profile.

A hiring manager, however, is not exactly a single type of position. For most organizations, a
hiring manager in the Sales department will almost certainly need access to a different type of
data than a hiring manager in Engineering. However, for the purposes of our app, sales managers
and software managers still need the same types of access to recruiting data—reviews, candidates,
positions, job applications, job postings, and employment websites. Let's keep this as a single
profile for now, but if incorporating our app into an organization with other CRM functionality,
we'll need to suggest as a best practice that the hiring manager permissions for recruiting-related
data need to be replicated for any profile to which hiring managers belong.

Finally, let's look at interviewers and standard employees. Neither one of these user types
reflects a particular job function, and when you think about it, just about anyone in an
organization might be called upon to perform an interview. Let's define a single profile for a
standard employee and find a way to grant interviewers access to the records that they need
through some other mechanism. (Hint: we can use a combination of organization-wide defaults
and sharing rules to make this work.)

139
Chapter 7: Securing and Sharing Data

Try It Out: Creating the Recruiter Profile

All right—we're finally ready to dig into the app and create our first profile! Let's start with
the Recruiter profile.

1. Click
ClickYour ➤ Setup Users
➤ Manage
Name
Setup ➤ Manage Users ➤ Profiles.
➤ Profiles,

Figure 46: Standard Profiles

Here you should see the list of standard profiles that we talked about earlier. After we create
our custom profiles, they'll also show up in this list.

First, we can quickly tell which profiles we can play with by looking at the Custom column—if
it's checked, that means it's a custom profile and we can edit anything about it. If that column
is not checked, we can still click the Edit link; we just can't modify any of the permission
settings. (What does that leave for us to edit on a standard profile? Well, we can choose which
tabs should appear at the top of a user's page, and we can also select the apps that are available
in the Force.com app menu in the top-right corner of the page.)

2. Create a new profile named Recruiter based on the Standard User profile.

There are actually two ways of doing this—we can either click New, select an existing profile
to clone, name it, and click Save, or we can simply click Clone in the detail page of the profile
that we want to copy, name it, and click Save. Ultimately, it's the same number of clicks, so
choose the method you like best. Standard User is the profile that most closely resembles what
we want our new Recruiter profile to look like, so it's a good starting point.

3. In the new Recruiter profile's detail page, click Edit.

The Recruiter edit page should look and function exactly like the Standard User profile edit
page except with one important difference: you have the ability to modify any of the permission
settings.

140
 Securing and Sharing Data

4. In the Custom App Settings area, make the Recruiting app visible to users assigned
to the Recruiter profile, as shown in the following screenshot.

Figure 47: Profile Custom App Settings Area

Tip: You can also give this profile access to any of the other available apps as well.
Every profile needs to have at least one visible app.

When an app is visible, a user can select it from the Force.com app menu at the top-right
corner of the page. Be aware, however, that even if an app is visible, the app's tabs won't show
up unless a profile has permissions to view the tabs and permission to view the associated
object. (We'll set both of those permissions lower down in the Profile edit page.)

5. Select Default next to the Recruiting app.

Making this selection means that the Recruiting app will be displayed when a user logs in.
You'll notice that when you select an app as the default, its Visible checkbox is automatically
selected, because it doesn't make sense for an app to be the default if it's not visible to the user.

6. In the Tab Settings area, select Default On for the Positions, Job Applications,
Candidates, and Employment Websites tabs.

Tip: You can choose whether you want other tabs to be displayed based on the
additional apps that you made visible in the last step.

For the purposes of our Recruiting app, all of our custom recruiting tabs are on by default. For
any other tabs that you select, you can choose which should be displayed on top of the user's
page (Default On), hidden from the user's page but available when he or she clicks the All
Tabs tab on the far right (Default Off ), or completely hidden from the user (Tab Hidden).

Realize that even if you completely hide a tab, users can still see the records that would have
appeared in that tab in search results and in related lists. (To prevent a user from accessing
data, we have to set the proper restrictions in the Standard and Custom Object Permissions
areas lower down in the Profile edit page—we'll get there shortly!)

The Overwrite users' personal tab customizations setting appears if you have
an organization that's currently in use and you want to make sure your existing users are viewing
the tabs that you've selected. You don't need to select this for our app because we're defining
141
Chapter 7: Securing and Sharing Data

a brand-new profile and no one has personalized his or her tab visibility settings yet. However,
if you do want to select this option at some point in the future, just make sure you're not going
to annoy your users by deleting all of their customizations!

Figure 48: Profile Tab Settings Area

Just below the Tab Settings area, the Administrative and General User Permissions areas of
the profile allow you to grant special access to features and functionality that don't map directly
to particular objects. None of these permissions affects our Recruiting app, but you can learn
more about them in the online help.

It's time to move on to the object-level permissions.

7. In the Custom Object Permissions area, specify the object-level permissions for our
Recruiter profile according to the following table.

Table 26: Summary of Required Permissions: Recruiter

Positions Candidates Job Reviews Job Posting Employment

Applications Website
Recruiter • Read • Read • Read • Read • Read • Read
• Create • Create • Create • Create • Create • Create
• Edit • Edit • Edit • Edit • Edit • Edit
• View • Delete • Delete
All • View • View
All All
• Modify • Modify
All All

142
 Securing and Sharing Data

Tip: Depending on the apps that you made visible previously, you can also set
additional object permissions on standard or other custom objects.

Since there are no instances when a recruiter should be allowed to delete positions, candidates,
job applications, and reviews, we should make sure that the object-level permissions for deletion
are turned off for these objects. Also, make sure the “View All” and “Modify All” permissions
are only selected for job postings and employment websites. These are special kinds of object
permissions that we'll discuss later in this chapter.

Figure 49: Recruiter Profile Permissions

By restricting the power to delete recruiting-related objects here, recruiters will never be able
to delete these objects. However, the fact that we're granting recruiters permission to create,
read, or edit our recruiting objects does not necessarily mean that recruiters will be allowed to
read or edit every recruiting object record. Why?

Here we see the result of two really important concepts in the platform:

• The permissions on a record are always evaluated according to a combination of object-,

field-, and record-level permissions.
• When object- versus record-level permissions conflict, the most restrictive settings win.
What this means is that even though we are granting this profile create, read, and edit
permissions on the recruiting objects, if the record-level permissions for an individual recruiting
record prove to be more restrictive, those will be the rules that will define what a recruiter can
access.

For example, our new profile gives a recruiter permission to create, edit, and view reviews.
However, if we set organization-wide defaults for reviews to Private (a record-level permission),
our recruiter will be allowed to edit and view only his own reviews, and not the reviews owned
by other users. We'll learn more about record-level permissions later and go through more
examples of how they work with the object-level ones, but for now, just understand that
object-level permissions are only one piece of the puzzle.

8. Click Save to create your profile and return to the profile detail page.
143
Chapter 7: Securing and Sharing Data

Congratulations! We're done with our first profile. As you can see, it really wasn't that hard,
because we'd already analyzed our required permissions and knew what objects recruiters will
need access to. In the next section, let's quickly finish up our other two profiles and then move
on to field-level security.

Try It Out: Creating More Profiles

Now that we've created our Recruiter profile, let's finish up with profiles for hiring managers
and standard employees. As we mentioned earlier, these profiles are probably too generic to
be used in a company that's using the platform for other, non-recruiting functionality, but for
our purposes, they'll work just fine for now.

To make each profile, go ahead and follow the steps that we outlined in the previous section.
The important things to remember for these profiles are:

• The profiles should be named Hiring Manager and Standard Employee and should be
based on the standard profile that best fits your needs. We used Standard User for our
Recruiter profile, and that's probably a good one for Standard Employee as well. However,
for your organization you might find that Hiring Manager more closely resembles the
Contract or Solution Manager profile instead. It's up to you.
• The Recruiting app for both profiles must be set to Visible.
• For the Hiring Manager profile, set the tabs for Positions, Candidates, Job Applications,
and Employment Websites to Default On.
• For the Standard Employee profile, set the tabs for Positions, Candidates, and Job
Applications to Default On, but set the tab for Employment Website to Tab Hidden.
• Standard and custom object permissions should reflect the required permissions that we
worked on before.

To refresh our memories, let's take a look at our required permissions summary table:

Table 27: Summary of Required Permissions: Hiring Manager, Interviewer, and Standard
Employee

Positions Candidates Job Reviews Job Employment

Applications Postings Websites
Hiring • Read • Read* • Read • Read • Read* • Read
Manager • Create (No • Edit • Create • Create*
• Edit* SSN) (No • Edit • Edit*
lookup
fields)

144
 Securing and Sharing Data

Positions Candidates Job Reviews Job Employment

Applications Postings Websites
Interviewer • Read • Read* • Read* • Read** - -
(No (No • Create
min/max SSN) • Edit**
pay)

Standard • Read - - - - -
Employee (No
min/max
pay)

* Only for those records that are associated with a position to which the hiring
manager/interviewer has been assigned

** Only for those records that the interviewer owns

This table is a little confusing right now, because Interviewer and Standard Employee are still
separated into two different users. Let's go ahead and combine them into a single Standard
Employee user so that it's a little easier to see what object-level permissions we need to grant.
It's easy to do, because Interviewers and Standard Employees have the same permissions on
the Position object, and we already have asterisks on Candidates, Job Applications, and Reviews
that ensures these users won't look at anything to which they're not assigned as an interviewer:

Table 28: Summary of Required Permissions: Combining Interviewers and Standard

Employees

Positions Candidates Job Reviews Job Employment

Applications Postings Websites
Hiring • Read • Read* • Read* • Read • Read* • Read
Manager • Create (No • Edit • Create • Create*
• Edit* SSN) (No • Edit • Edit*
lookup
fields)

Standard • Read • Read* • Read* • Read** - -

Employee (No (No • Create
(Interviewer) min/max SSN) • Edit**
pay)

145
Chapter 7: Securing and Sharing Data

* Only for those records that are associated with a position to which the hiring manager/standard
employee has been assigned

** Only for those records that the standard employee owns

Great, but what about all of those asterisks and restrictions on visible fields? Do we need to
take those into account when we set our object-level permissions?

Not at all. Those asterisks and field restrictions represent record- and field-level security settings
that we're going to have to specify elsewhere in our app. The only things we need to care about
here are the permissions that these users will need to have access to at least some of the
time—that's the whole point of object-level permissions:

• For hiring managers, that's create, read, and edit on Positions and Reviews, read on
Candidates and Employment Websites, and read and edit on Job Applications
• For standard employees, that's read on Positions, Candidates, and Job Applications, and
create, read, and edit on Reviews

Figure 50: Hiring Manager Profile Permissions

Figure 51: Standard Employee Profile Permissions

Fantastic! We've just finished defining profiles and object-level permissions for all the users
in our Recruiting app.

146