Force.com Platform Fundamentals

Preface
Introducing the Force.com Platform
About the Sample Recruiting App
Reviewing Database Concepts
Building a Simple App
Enhancing the Simple App with Advanced Fields, Data Validation, and Page Layouts
Expanding the Simple App Using Relationships
Securing and Sharing Data
Controlling Access to Data in Our App
Data Access Concepts
Controlling Access to Objects
Controlling Access to Fields
Controlling Access to Records
Introducing Organization-Wide Defaults
Org-Wide Defaults in Our Recruiting App
Try It Out: Set Org-Wide Defaults
Introducing Role Hierarchies
Comparing Roles, Profiles, and Permission Sets
Role Hierarchies in Our Recruiting App
Try It Out: Create a User
Try It Out: Define a Role Hierarchy
What's Left to be Shared?
Introducing Sharing Rules
Sharing Rules in Our Recruiting App
Try It Out: Define a Public Group
Try It Out: Define Sharing Rules
Introducing Manual Sharing
Try It Out: Define a Manual Sharing Rule
Displaying Field Values and Page Layouts According to Profiles
Putting It All Together
Delegating Data Administration
Summing Up
Collaborating with Chatter
Using Custom Workflow and Approval Processes
Analyzing Data with Reports and Dashboards
Moving Beyond Point-and-Click App Development
Learning More
Glossary
PDF

Newer Version Available

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

Org-Wide Defaults in Our Recruiting App

To determine the org-wide defaults that we'll need in our Recruiting app, we need to answer the following questions for each object:
  1. Who is the most restricted user of this object?
  2. Is there ever going to be an instance of this object that this user shouldn't be allowed to see?
  3. Is there ever going to be an instance of this object that this user shouldn't be allowed to edit?

Based on our answers to these questions, we can determine the sharing model that we need for that object as illustrated in the following diagram.

Determining the Sharing Model for an Object A diagram for determining the sharing model for objects
For example, let's consider the Position object in our recruiting app. To refresh our memories, here's our table of required permissions:
Table 1. Revised Summary of Required Permissions
Recruiter Hiring Manager Standard Employee
Position Read Create Edit Read Create Edit* Read (No min/max pay)
Candidate Read Create Edit Read* (No SSN) Read* (No SSN)
Job Application Read Create Edit Read Edit (No lookup fields) Read*
Review Read Create Edit Read Create Edit Read** Create Edit**
Job Posting Read Create Edit Delete Read*Create*Edit*
Employment Website Read Create Edit Delete Read

* 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

Now let's go through and answer our list of questions for the Position object:
1. Who is the most restricted user of this object?
A member of the Standard Employee profile. All that they're allowed to do is view a position.
2. Is there ever going to be an instance of this object that this user shouldn't be allowed to see?
No. Although the values for the minimum and maximum pay are hidden from standard employees, they're still allowed to view all position records.
3. Is there ever going to be an instance of this object that this user shouldn't be allowed to edit?
Yes. Standard employees aren’t allowed to edit any position record.

According to our flowchart, answering “Yes” to question #3 means that the sharing model for the Position object should be set to Public Read-Only.

The same is true for the Employment Website and Job Posting objects, except hiring managers are the most restricted users instead of standard employees. (Standard employees have no permissions on these objects, but of the users that do have permissions, hiring managers are most restricted.) We want to allow hiring managers to view all employment website and job posting records without being able to edit them, so the answer to the second question is “No” while the answer to the third question is “Yes;” therefore, the sharing model for the Employment Website and Job Posting objects should be Public Read-Only.

Going through the rest of our recruiting objects required permissions, we can easily figure out their sharing models, too. The Standard Employee profile is the most restricted user for each object, and there are going to be candidate, job application, and review records that particular employees won't be able to view. Consequently, the sharing model for the Candidate, Job Application, and Review objects should all be set to Private.