To provide a security model that satisfies numerous, unique real-world business cases, Salesforce provides a comprehensive and flexible data security model to secure data at different levels. Salesforce also provides sharing tools to open up and allow secure access to data based on business needs. In this post, I explain how security features work together by taking a real-world scenario and describing it using images and GIFs. This post serves as a primer on the Salesforce Data Security Model. Fore more in-depth information about the Security Model, see the Protect Your Salesforce Data Trailhead trail, and the reading material at the end of this post.

The basics

In Salesforce, data is stored in three key constructions: objects, fields, and records. Objects are similar to tables in databases. Fields are similar to columns of the table. Records are similar to rows of data inside the table. Salesforce uses object-level, field-level, and record-level security to secure access to object, field, and individual records.

The scenario

Maria is an experienced leader who has recently joined ABC Corp as a sales executive. She also has a marketing background and reports directly to the CEO. She needs access to various objects and apps in Salesforce.

Layer 1: Object-level-security

Before allowing a user access, Salesforce first verifies that the user has permissions to see objects of that type. Object-level access can be managed through two configurations, profiles and permission sets.

1.1 Profiles

In Salesforce, profiles control access to object-level and field-level security among other things like apps, tabs, and so on.

Since Maria is a new employee, an admin needs to add Maria to the appropriate profile that has access to sales apps and related objects to begin giving her access to Salesforce data.

1.2 Permission sets

Since Maria has a marketing background, let’s say she wants to access the Campaigns object to help with marketing. But since she is already part of a sales profile, if an admin adds CRUD (Create, Read, Update, and Delete) to Campaigns, then everyone in the profile is able to access Campaigns. The admin wants to give permission to access Campaigns just to Maria. This is where permission sets come in. Permission sets are used to provide additional (usually special) permissions to users who are already in a profile. In our case, an admin needs to create a permission set that provides access to the Campaigns object and assign that permission set to Maria.

Notes about permission sets:

  • With permission sets, you can add and remove permissions to a small subset of users at any time.
  • You can add multiple permission sets to a given user.
  • Use permission sets only when a subset of users need additional permissions.
  • If a lot of people in a profile need that permission, then create a custom profile and add permission directly to that profile.

Layer 2: Field-level-security

Even if Maria has access to objects, she still needs access to individual fields of each object. In Salesforce, profiles also control field-level access. An admin can provide read and write permissions for individual fields. An admin can also set a field to hidden, completely hiding the field to that user.

The graphic here shows how an admin provides field-level access.

Layer 3: Record-level security

With just object-level access and field-level access, Maria can only access records she owns (that is, records created by her). But if you look at the organization structure, she reports to Marc (CEO) and has two sales reps (Wendy and Bob) reporting to her.

This graphic illustrates the organization structure:

This is where record-level security comes in. Salesforce provides five ways to share records with others and access others’ records.

Five types of record-level security (also known as record sharing rules)

Showing five types of Record level sharing permissions

3.1 Record-level-security: organization-wide sharing defaults

In Salesforce, records have a field called “OwnerId” that points to a real user. Owners of records are usually people who created the record and have full CRUD access to it. Salesforce provides other ways to automatically assign ownership to users and to transfer ownership from one user to another user.

Organization-wide defaults (OWD) control the default behavior of how every record of a given object (for example, Accounts) is accessed by users who do not own the record.

For example:

  1. If OWD for Accounts is Private, it means Maria can only see records she is a owner of.
  2. If OWD for Accounts is Read/Write, it means anyone can read and update (but not delete) the record.

3.2 Record-level-security: role hierarchies

Virtually all companies have an organization structure where groups of people report to their managers and their managers in turn report to their managers, forming a tree-like org chart. In order to simplify sharing, Salesforce provides an easy way to share records with managers. To use this sharing rule, an admin must first add the user to a role and grant access.

In our case, the admin needs to add Maria to the appropriate role within Maria’s user record.

3.3 Record-level-security: sharing rules

Hierarchy-based sharing only works for sharing upward and in a vertical direction. What if we want to share laterally? For example, what if we want to share records that Maria owns with her peers in the service executive teams? This is where sharing rules come in. Sharing rules provides a way to share records laterally and in an ad-hoc fashion via public groups. Let’s look into the details.

3.3.1 Ownership-based sharing rules

Ownership-based sharing rules let admins share records based on role, role-and-subordinate, and public group ownership.

For example, we can share all the records owned by anyone in a sales executive role (including Maria’s) with everyone in a service executive role. Similarly, we can share all the records owned by the sales executives, and their subordinates, with others as well.

The GIF shows how different ownership-based sharing works for our use case. Note that the public group is an ad-hoc group of individual users, users in various roles, and other public groups. Sharing with public groups provides a highly flexible way to share records.

3.3.2 Criteria-based sharing rules

Criteria-based sharing rules let users access records based on the value of a field in a record, irrespective of who owns the record. For example, if Maria wants to meet with all accounts in San Francisco, she might set a criteria-based sharing rule on all accounts whose billing city is San Francisco.

3.4 Record-level-security: manual sharing (Classic only)

Record-level-security provides a mechanism to share individual records with others. This permission is accessed through the Sharing button on the record details page, and lets end-users share individual record with others.

Note: This is only available if the OWD is private or public read-only because otherwise (say public read/write), you wouldn’t need it.

3.5 Record-level-security: Apex managed sharing

There are occasions when you can’t share records via UI or settings, but you need to write Apex code to do so. For example: If Maria wants to share a record with just a single user (not roles, roles and subordinates, public groups), then she needs to ask the admins to create an Apex managed sharing rule. Learn more about Apex managed sharing.

Summary

Salesforce provides three layers of security with lots of flexibility to accommodate virtually any business need. Profiles controls object-level and field-level access. Permission sets are used to provide access to additional objects. Field-level security controls provide access to individual fields within an object. Further, there are five types of record-level security: org-wide defaults, role hierarchy sharing, sharing rules, manual sharing, and Apex-based sharing. These five control access to sets of records or even an individual record to people who don’t own those records.

Explore Furthur :

  1. Protect Your Salesforce Data—Trail
  2. Sharing Settings, Field Access and others in the Salesforce docs
  3. Record-Level-Access Under the Hood—PDF
  4. Sharing Architecture—PDF