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
Displaying Field Values and Page Layouts According to Profiles
Putting It All Together
Delegating Data Administration
Overriding Sharing with Object Permissions
Delegated Administration Groups
Try It Out: Define the Recruiting Manager Administration Group
Try It Out: Verify that Delegated Administration Works
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

Overriding Sharing with Object Permissions

Believe it or not, we already delegated a few administrative responsibilities a few pages ago when we created the Recruiter permission set. If you go back to that section, you'll see that we selected the “View All” and “Modify All' object permissions for job postings and employment websites. As you might expect, “View All” lets users view all of the records of that object, while “Modify All” lets users read, edit, and delete all of the records of that object. So how does selecting these permissions differ from just selecting the “Create,” “Read,” “Edit,” and “Delete” permissions individually? And how do “View All” and “Modify All” help you delegate administration?

The keyword here is “all.” When you grant “View All” or “Modify All” for an object on a profile or permission set, you grant any associated users access to all records of that object regardless of the sharing and security settings. In essence, the “View All” and “Modify All” permissions ignore the sharing model, role hierarchy, and sharing rules that the “Create,” “Read,” “Edit,” and “Delete” permissions respect. Furthermore, “Modify All” also gives a user the ability to mass transfer, mass update, and mass delete records of that specific object, and approve such records even if the user is not a designated approver. These tasks are typically reserved for administrators, but because “View All” and “Modify All” let us selectively override the system, responsibilities that are usually reserved for the administrator can be delegated to other users in a highly controlled fashion.

We'll learn more about approving records in the next chapter. Other administrative actions, such as mass updates, are covered in the Salesforce online help.

Note

You may wonder if the “View All” and “Modify All” object permissions are similar to the ���View All Data” and “Modify All Data” global permissions. It’s true that they all ignore the sharing model, hierarchy, and sharing rules, but bear in mind that object permissions only apply to records of a specific object, whereas global permissions apply to records of every object in your organization. As a rule of thumb, when global administration permissions are too permissive for a particular user, use the object permissions instead to control data access on an object-by-object basis.

Because we already applied object permissions when we created the Recruiter permission set, there's no need to walk through the process again here; however, you can probably imagine other ways in which the “View All” and “Modify All” permissions might be useful for this app. For example, as we discussed before, certain laws may require your company to keep all position, candidate, and job application records for a specific amount of time. This law is why we opted not to give recruiters the ability to delete those records. When that legal time limit expires, though, your company may want to hire a contractor who specializes in data cleansing to remove old recruiting data from the system. By creating a permission set with the “Modify All” object permission on positions, candidates, and job applications, you can quickly give the contractor the permissions needed to get the job done without exposing the rest of your company's data.