Control Access to Records

Learning Objectives

After completing this unit, you’ll be able to:

• List the four ways to control access to records.
  
• Describe situations in which to use each of the four record-level security controls.
  
• Explain how the different record controls interact with each other.
  
• Set org-wide sharing defaults to control access to records.
  

Record-Level Security

To control data access precisely, you can allow particular users to view specific fields in a specific object, but then restrict the individual records they’re allowed to see. Record access determines which individual records users can view and edit in each object they have access to. First ask yourself these questions:

• Should your users have open access to every record, or just a subset?
  
• If it’s a subset, what rules should determine whether the user can access them?
  

For the example Recruiting app, you created a new permission set group called Recruiters to give recruiters the object-level permissions they need. You restricted the power to delete recruiting-related objects, so recruiters can’t ever delete these objects. However, granting recruiters permission to create, read, or edit recruiting objects doesn’t necessarily mean recruiters can read or edit every record in the recruiting object. This behavior occurs because record-level security controls the access that users have to records they don’t own.

Record-level features offer layers of increasing access, so it’s important to know which record-level features are configured and how to understand the level of access a user has.

You control record-level access in four ways. They’re listed in order of increasing access. You use organization-wide defaults to lock down your data to the most restrictive level, and then use the other record-level security tools to grant access to selected users, as required.

• Organization-wide defaults specify the default level of access users have to records they don’t own.
  
• Role hierarchies ensure managers have access to the same records as their subordinates. Each role in the hierarchy represents a level of data access that a user or group of users needs.
  
• Sharing rules are automatic exceptions to organization-wide defaults for particular groups of users, to give them access to records they don’t own or can’t normally see.
  
• Manual sharing lets record owners or users with sufficient permissions give read and edit access to users who don’t have access to the record any other way.
  

The visibility and access for any type of data is determined by the interaction of the above security controls, based on these key principles.

• A user’s baseline permissions on any object are determined by their combined permission sets, permission set groups, and profile.
  
• Access to records a user doesn’t own are set first by organization-wide defaults.
  
• If the organization-wide defaults are anything less than Public Read/Write, you can open access back up for certain roles using the role hierarchy.
  
• You can use sharing rules to expand access to additional groups of users.
  
• Each record owner can manually share individual records with other users by using the Share button on the record.
  

Salesforce offers additional features for managing record access that can be useful depending on your business needs. For more information, see Set Up Record Access for Your Users in Salesforce Help.

You spend the rest of this module learning more about controlling access to records. In this unit, you delve into configuring organization-wide defaults.

Organization-Wide Defaults

Organization-wide defaults (or org-wide defaults for short) specify the baseline level of access that users have to records they don’t own. The setting should represent the access the most restricted user should have. Use org-wide defaults to lock down your data, and then use the other record-level security and sharing tools (role hierarchies, sharing rules, and manual sharing) to open up the data to users who need it.

Object permissions determine the baseline level of access for all the records in an object, and org-wide defaults modify those permissions for records a user doesn’t own. Org-wide defaults can never grant users more access than they have through their object permission. Org-wide defaults can be set separately for each type of object and for internal vs. external users.

To determine the org-wide defaults you need for your app, ask yourself these questions about 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 your answers, you can set the sharing model for that object to one of these settings.

• Private: Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records.
  
• Public Read Only: All users can view and report on records, but only the owner, and users above that role in the hierarchy, can edit them.
  
• Public Read/Write: All users can view, edit, and report on all records.
  
• Controlled by Parent: A user can view, edit, or delete a record if they can perform that same action on the object it belongs to.
  

When the org-wide sharing setting for an object is Private or Public Read Only, an admin can grant users additional access to records by setting up a role hierarchy or defining sharing rules. Sharing rules can only be used to grant additional access. They can’t be used to restrict access to records beyond what was originally specified with the org-wide sharing defaults.

As an example, let’s answer the above list of questions for the Position object in the Recruiting app.

1. Who is the most restricted user of this object?
   

A standard employee, who is only allowed to view a position.

2. Is there ever going to be an instance of this object that this user can’t be allowed to see?
   

No. Although the values for the minimum and maximum bonus fields 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 can’t be allowed to edit?
   

Yes. Standard employees aren’t allowed to edit any position record.

Since the answer to the third question is “Yes,” the sharing model for the Position object should be set to Public Read Only. By repeating the same exercise with the other recruiting objects, you can easily figure out the appropriate org-wide default settings for them. Standard employees are 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.

You can’t set the org-wide defaults for the Review object, because that object is on the detail side of a master-detail relationship, and a detail record automatically inherits the sharing setting of its parent. So in your app, the Review object is automatically set to Private.

Set Your Org-Wide Sharing Defaults

Use org-wide defaults to specify the baseline level of access that the most restricted user should have.

1. From Setup, in the Quick Find box, search for and select Sharing Settings.
   
2. Click Edit in the Organization-Wide Defaults area.
   

3. For each object, select the default internal access and default external access. As you learned earlier, you set the default internal access for Position to Public Read Only and for Candidate, Job Application, and Review to Private. You set the default external access for all four objects to Private.
   

Some standard objects use different org-wide default options. Custom object org-wide default options include Private, Public Read Only, or Public Read/Write.

4. To disable automatic access via the role hierarchy, you can deselect Grant Access Using Hierarchies for any custom object that doesn’t have a default access of Controlled by Parent. If you deselect this checkbox, only the record owner and users granted access through sharing features receive access to the records.
   
5. Click Save when you finish setting access.
   

Updating the org-wide defaults automatically runs sharing recalculation to apply any access changes to your records. You receive a notification email when the recalculation completes and you can refresh the Sharing Settings page to see your changes. To view the update status, from Setup, in the Quick Find box, search for and select View Setup Audit Trail.

After you lock down your data with org-wide defaults, the resulting settings might be too restrictive for some users. You can then use other record-level security controls, such as role hierarchies, sharing rules, and manual sharing, to open up record access selectively to specific employees who need it.

Resources

• Salesforce Help: Set Up Record Access for Your Users
• Salesforce Help: Organization-Wide Sharing Defaults
• Salesforce Help: Sharing Considerations