A Look at the Salesforce Record-Level Security Model

June 10, 2016 Appirio

By Sahil Batra


Data security is an essential part of every organization. A small cyber attack can ruin a big business. Every company has sensitive data; it can be customer data, financial data, employee data, or other personal details. Many organizations invest a lot of money into securing their data from security breaches. Now the question becomes: How does Salesforce provide data security?

Salesforce provides various techniques to ensure data security. These techniques include:

  • Organization-level security
  • Object-level security
  • Record-level security
  • Field-level security
  • Folder-level security

Record-level security answers the question “Who can access what?” Salesforce helps you to:

  • Ensure the data security of your confidential customer data and other company data.
  • Restrict access to sensitive data.
  • Give people access to the records they need to work on or collaborate on.
  • Promote efficiency without exposing sensitive information.
  • Restrict searches in order to show only relevant records.

Record-level security pillars (aka who can access what?)

RLSM1There are 4 different pillars that control record-level sharing among different sets of users. The different pillars are:

  1. Organization-wide defaults.
  2. Role hierarchy.
  3. Sharing rules.
  4. Manual sharing and team sharing.


Let’s take a look at each of these pillars…

Organization-wide defaults
The Organization-wide default (OWD) controls the default object-level record access. In other words, it defines the level of access each user has for records for a particular object. OWD provides the baseline-level access to a particular record for an object. Here are how the other settings work:

  • Private sharing model allows only the record owner to manage the record, assuming they have all profile permission for that object.
  • Read-only sharing model provides read access to all users to all the records for an object, assuming that user has read permission on their profile for that object.
  • Read/write sharing model provides read and write access to all users to all records for an object, assuming the user has the required profile permissions.

Additionally, in a master-detail relationship, the child object OWD is always controlled by the parent record. In other words, if a user has access to the parent record, she can also access its child records — assuming that user has the required profile permissions.

The role hierarchy

Role hierarchy refers to a set of roles in an organization and the relationship between different roles. Admins can find roles by navigating via: Setup > Manage Users > Roles.

RSLM2The role hierarchy opens up vertical-level access to records. For a manager, there is often a scenario in which they need to report on records for people below them in the organization. This access is provided via roles and hierarchy.

If an object has the private sharing model and the record created by a worker needs to be visible to their manager, then we need to grant access by marking the hierarchies checkbox in OWD settings. This way, records will roll up and each role above the record owner will inherit full ownership for those records. (The hierarchy always rolls up. They are never shared to the branches of the hierarchy.)

Sharing rules

Roles always provide vertical-level access, but consider a scenario in which we need to share records across a hierarchy (i.e., we need to share a record of one worker with another worker.) Sharing rules provide us a way to share records horizontally. Sharing rules are based on record ownership or criteria setting and are necessary only if we have a private sharing model.

Record ownership sharing rules share records based on the ownership of the records, and criteria setting shares the records based on field value filters that match the criteria. The sharing rules share the records with the following:

  • Public groups.
  • Roles.
  • Roles and subordinates.

We can define the level of access for a sharing rule as read-only or read/write.

Manual sharing

If an object is in the private sharing model, there is a sharing button on every record that allows the record owner or manager to share the record with another user. This technique is used to share one record at a time.

Three types of users can do manual sharing:

  • System admin.
  • Record owner.
  • Record owner manager.

So, the single record can be shared to a single user as needed.

We can also manually share records using Apex manual sharing. For each object with private OWD there exists a share object (i.e., StandardObjectShare and, for custom objects, CustomObject__Share.) Here is a code snippet for sharing records using Apex: (Note: Consider an Object Install_Base__c with private OWD.)


Team sharing

Team sharing is an option for sharing with groups of people. For this type of sharing there are 3 types of teams:

  • Account teams.
  • Opportunity teams.
  • Case teams.

Account teams allow users to add members to account teams and grant read-only or read/write access to an account and its related contacts, opportunities, and so on. An opportunity team allows users to add team members manually and set their roles on opportunity teams based on the roles, grant read-only or read/write access for each member, and do the same with a case team.

To learn more about security, check out Salesforce’s Security Workbook and Jason Curtis’s review of Trailhead’s security module.

Previous Article
Factors Guiding QA Closure
Factors Guiding QA Closure

By Amrita Jain Ever wonder how much testing is enough testing? We may be confident through many phases of t...

Next Article
An Introduction to Veeva: CRM for the Life Sciences
An Introduction to Veeva: CRM for the Life Sciences

By Sourabh Sharma Veeva is a CRM application built on the Salesforce platform designed specifically for the...