Attention Trailblazer!

Salesforce has two different user interfaces: Lightning Experience and Salesforce Classic. It’s easy to switch between the two. You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.

This module is designed for Salesforce Classic.

Learning Objectives

After completing this unit, you will be able to:
  • Explain the importance of securing access to data.
  • List the four different levels at which you can control data access on the platform.
  • Describe a typical use case for limiting data access at each of the four levels.


Choosing the data set each user or group of users can see is one of the key decisions that affects the security of your app. Once you’ve designed and implemented the data model for your app, it’s important to think about the different types of users and the types of data they need access to.

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.

The platform 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 all users can easily access the data they need.

The platform 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.



Although you can configure the security and sharing model entirely using the user interface, it is implemented at the API level. That means any permissions you specify for objects, records, and fields apply even if you query or update the data via API calls. This ensures the security of your data is protected, regardless of how it is accessed.

Watch this video to get an overview of the different ways to manage access to data.

Levels of Data Access

There are four main levels at which you can configure access to data on the platform.


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.

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.
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.
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 an interviewer to see and edit her own reviews, without exposing the reviews of other interviewers. You can manage record-level access in these four 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 record-level security and sharing tools to selectively give access to other users.
  • 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 should represent a level of data access that a user or group of users needs.
  • 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 additional users access to records—they can’t be stricter than your organization-wide default settings.
  • 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.

The following units provide more details about each of these methods for controlling data.



When implementing security and sharing rules for your organization, make a table of the various types of users in your organization. In the table, specify the level of access to data that each type of user needs for each object and for fields and records within the object. You can then refer to this table as you set up your security model.

Controlling Data Access with the Platform A diagram of the sharing and security settings available for different types of users

Audit System Usage

Auditing features does not secure your organization by itself. It provides important information about system usage, which can be useful in diagnosing potential or real security issues. It is important that someone in your organization perform regular audits to detect potential abuse. The other security features provided by Salesforce are preventative. To verify that your system is secure, perform audits to monitor for unexpected changes or usage trends.

Auditing features include:

Record Modification Fields
All objects include fields to store the name of the user who created the record and who last modified the record. This provides some basic auditing information.
Login History
You can review a list of successful and failed login attempts to your organization for the past six months. For more information, see Monitoring Login History.
Field History Tracking
You can also enable auditing for individual fields, which will automatically track any changes in the values of selected fields. Although auditing is available for all custom objects, only some standard objects allow field-level auditing. For more information, see Tracking Field History.
Setup Audit Trail
Administrators can also view a Setup Audit Trail, which logs when modifications are made to your organization’s configuration. For more information, see Monitor Setup Changes.
Share Time Estimate

Having trouble with your challenge verification?

Here are some tips:

  1. Check for typos (hey, it happens)
  2. Try using a new Developer Edition (existing customizations can interfere with the validation)