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
Automating Business 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

Introducing Manual Sharing

Now let's talk about what we have left to do to finish defining our sharing model. After implementing our sharing rules, the following required permissions remain:
  • Hiring managers need read and update access on position records on which they're the hiring manager.
  • Hiring managers need read access on candidate records on which they're the hiring manager.
  • Interviewers need read access on the candidate and job application records for people they're interviewing.

We didn't implement those required permissions with sharing rules because it was too hard for us to come up with a consistent group of users who would need access to a particular set of records. Really, this is where the job of the recruiter comes into play. A recruiter like Mario Ruiz owns the position, candidate, and job application records for jobs that he's trying to fill, and he also knows the hiring manager and interviewers who should be assigned to them.

Fortunately, we have one final type of record-access setting that allows Mario to share specific records with other specific users: manual sharing. With manual sharing, Mario can grant read or read/write access on records that he owns to any other user, role, or public group. Although it isn't automated like organization-wide defaults, role hierarchies, or sharing rules, manual sharing gives Mario the flexibility to share particular records with the ever-changing groups of interviewers and hiring managers with whom he has to deal every day.