Start tracking your progress
Trailhead Home
Trailhead Home

Control What Your Users Can Access

Learning Objectives

After completing this unit, you’ll be able to:
  • Describe the difference between object and field level security
  • Describe how to set org–wide default sharing settings

Introduction to Data Security

Now that you know how to add users, you probably want to know how to make sure they can see what they need to see and only what they need to see. In this unit, we show you how to configure your users' access to your Salesforce records so they can access only the information they need.

For example, suppose you're building a Recruiting app that contains information about open positions, candidates, and job applications. The app will store confidential data, such as social security numbers, salary amounts, and applicant reviews that should only be exposed to specific types of users. For such an app, it's important to secure the sensitive data without making it harder for recruiters, hiring managers, and interviewers to do their jobs.

Salesforce provides a flexible, layered sharing model that makes it easy to assign different data sets to different sets of users. This ensures you can balance security and convenience, minimizing the risk of stolen or misused data while making sure that all users can easily access the data they need.

Salesforce includes simple–to–configure security controls that make it easy to specify which users can view, create, edit, or delete any record or field in the app. You can configure access at the level of the organization, objects, fields, or individual records. By combining security controls at different levels, you can provide just the right level of data access to thousands of users without having to specify permissions for each user individually.

Levels of Data Access

You can configure access to data in Salesforce at four main levels.

Organization
At the highest level, you can secure access to your organization by maintaining a list of authorized users, setting password policies, and limiting login access to certain hours and certain locations.
Objects
Object–level security provides the simplest way to control which users have access to which data. By setting permissions on a particular type of object, you can prevent a group of users from creating, viewing, editing, or deleting any records of that object. For example, you can use object permissions to ensure that interviewers can view positions and job applications but not edit or delete them.
Fields
You can use field–level security to restrict access to certain fields, even for objects a user has access to. For example, you can make the salary field in a position object invisible to interviewers but visible to hiring managers and recruiters.
Records
To control data with greater precision, you can allow particular users to view an object, but then restrict the individual object records they're allowed to see. For example, record–level access allows interviewers to see and edit their own reviews, without exposing the reviews of other interviewers. You can manage record–level access in the following ways.
  • Organization–wide defaults specify the default level of access users have to each others' records. You use organization–wide sharing settings to lock down your data to the most restrictive level, and then use the other sharing tools to selectively give access to other users. For example, you can give all employees access to an object called Candidate to allow anyone to add a candidate to the database. But you can restrict access to Positions so that anyone can see the jobs available but only the employees with the proper permissions can edit them.
  • Role hierarchies open up access to those higher in the hierarchy so they inherit access to all records owned by users below them in the hierarchy. Role hierarchies don't have to match your organization chart exactly. Instead, each role in the hierarchy represents a level of data access that a user or group of users needs. For example, you can restrict access to Candidates by setting the organization–wide default to Private, but allow recruiters to view and edit the candidate records that they own. Recruiters can't see candidate records they don't own because recruiters are all at the same level in the role hierarchy. However, hiring managers can be given read/write access to all candidate records because they are at a higher level in the role hierarchy than recruiters.
  • Sharing rules enable you to make 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. Sharing rules, like role hierarchies, are only used to give more users access to records—they can't be stricter than your organization–wide default settings. For example, you can allow all employees to view Positions, but use sharing rules to grant full editing access to employees in a role or group called Hiring Managers.
  • Manual sharing allows owners of particular records to share them with other users. Although manual sharing isn't automated like organization–wide sharing settings, role hierarchies, or sharing rules, it can be useful in some situations, for example, if a recruiter going on vacation needs to temporarily assign ownership of a job application to another employee.

Overview of Record–Level Security

You can control data access with greater precision by allowing particular users to view an object, but then restricting the individual records within the object they're allowed to see. For example, you can give all your interviewers access to reviews with organization–wide defaults, but restrict their access to only reviews they own with role hierarchies.

Before configuring record access, you might find it useful to answer the following 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?
Let's say you create a profile called Recruiter so you can create object–level permissions for recruiters. You can restrict the power to delete recruiting–related objects, like Positions or Candidates, so recruiters will never be able to delete these objects. However, the fact that you're granting recruiters permission to create, read, or edit recruiting objects does not necessarily mean recruiters are allowed to read or edit every recruiting object record, like individual positions or candidates. This is a consequence of two 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 if you grant a 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 are the rules that define what a recruiter can access. For example, if you give the Recruiter profile create, read, and edit permissions on the Candidates object but restrict recruiters' access to only the Candidate records they own, recruiters are only able to access those records.

Organization–Wide Sharing Defaults

Now that you’ve learned more about record–level security, let's focus on organization–wide defaults. These are the defaults that specify the baseline level of access that the most restricted user should have. You can use organization–wide defaults to lock down your data to this most restrictive level, and then use other record–level security and sharing tools (role hierarchies, sharing rules, and manual sharing) to open up the data to other users who need to access it.

You can specify the default level of access to records with organization–wide sharing settings and you can set them separately for each type of standard or custom object. You can determine the baseline level of access for all records of an object with object permissions. You can modify those permissions for records users don't own with organization–wide defaults. You can never use organization–wide defaults to grant users more access than they have through their object permission.

You can determine the organization–wide defaults you need for your app by answering 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?
A diagram for determining the sharing model for objects

Based on your answers to these questions, you can set the sharing model for that object to one of these settings.

Field Description
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 not edit them. Only the owner, and users above that role in the hierarchy, can edit those records.

Public Read/Write All users can view, edit, and report on all records.
Controlled by Parent

A user can perform an action (such as view, edit, or delete) on a contact based on whether he or she can perform that same action on the record associated with it.

In environments where you've set the organization–wide sharing setting for an object as Private or Public Read Only, you can grant users more access to records by setting up a role hierarchy or defining sharing rules. However, you can only use sharing rules to grant more access—they cannot be used to restrict access to records beyond what was originally specified with the organization–wide sharing defaults.

As an example, let's go through and answer the list of questions for the Position object in the Recruiting app.
  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 the flowchart, answering "Yes" to question #3 means that 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 organization-wide default settings for them. 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 shouldn't be able to view. Consequently, you should set the sharing model for the Candidate, Job Application, and Review objects to Private.

Note

Note

You can't set the organization–wide defaults for the Review object. This is 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 our app, the Review object is automatically set to Private .

Set Organization-Wide Sharing Defaults

Now that you’ve read about org-wide defaults, you’re ready to set some.

  1. From Setup, enter Sharing Settings in the Quick Find box, then select Sharing Settings.
  2. Click Edit in the Organization-Wide Defaults area.
  3. For each object, select the default access you want to use. (Recall the questions you answered in the previous section to help you figure out which default access setting is most appropriate.)
  4. To allow employees at higher levels in the role hierarchy to access records automatically, select Grant Access Using Hierarchies for any custom object that does not have default access of Controlled by Parent.

In environments where the organization-wide sharing setting default for an object is set to Private or Public Read Only, you can grant users more access to records by setting up a role hierarchy or defining sharing rules. Just remember, you can only use sharing rules to grant more access. You cannot use them to restrict access to records beyond what was originally specified with the organization–wide sharing defaults.

By default, Salesforce uses hierarchies, like a role hierarchy, to automatically grant record access to users above the record owner in the hierarchy. Setting an object to Private makes those records visible only to record owners and users above them in the role hierarchy. If you want to disable access to records for users above the record owner in the hierarchy for custom objects, use the Grant Access Using Hierarchies checkbox. If you deselect this checkbox for a custom object, you restrict record access to only the record owner and users granted access by the organization–wide defaults.

If you deselect Grant Access Using Hierarchies, users that are higher in the role hierarchy don't receive automatic access. However, some users can still access records they don't own by default—such as users with the "View All" and "Modify All" object permissions and the "View All Data" and "Modify All Data" system permissions.

When you update the organization-wide defaults, you cause a sharing recalculation to run automatically and 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 updated status, from Setup, enter View Setup Audit Trail in the Quick Find box, then select View Setup Audit Trail.

Once you've secured your data with organization-wide defaults, the resulting settings might be too restrictive for some users. You can then use the remaining record-level security controls: role hierarchies, sharing rules, and manual sharing to open up record access selectively to specific employees who need it.

retargeting