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

There are three key constructs related to data in Salesforce: 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 have historically been the way to control access to object-level and field-level security. However, since permission sets were released, we recommend to use them as the primary way to configure object and field permissions, together with permission set groups. Note that assigning each user a profile is still compulsory, as this is the place where you configure other things like page layout assignments or login IP restrictions. However, for object and field security setup, configure profiles for minimum access and use permission sets and permission set groups to add permissions.

1.2 Permission sets and Permission Set Groups

Since Maria is a new employee, an admin needs to assign Maria to the appropriate permission sets that grant her access to the sales apps and related objects.

We recommend permission sets as the primary way to assign object and field permissions. Here’s why:

They are more flexible.
They are packageable.
They are upgradeable too.

While packageability and upgradeability are self-explanatory, let’s look at how permission sets and permission set groups are more flexible. In contrast to profiles, you can add multiple permission sets to a given user. This gives you much more flexibility at the time of designing your security model, as functionality can be grouped in more granular ways. When only using profiles, you needed to group all the object and field permissions in a single profile, for instance for a concrete job role, as sales exec. With permission sets you can have different permission sets representing the different tasks that that a sales exec performs: manage leads, approve opportunities, etc. and add or remove smaller chunks of permissions to a user at any time.

Because of the granular nature of permission sets, you can end up with lots of permission sets in your organization. To manage them in a simpler way you can group them in permission set groups. That way, Maria can be assigned a permission set group in one action. This means the grouped permission sets are summed into the permission set group and assigned to Maria as a single artifact.

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 and permission sets 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 removing access to the field to from that user. When you hide a field with field-level security , the field won’t be accessible through any entry points (for instance via API). The recommended security best practice is to use field-level security instead of just removing a field from a record page or page layout. Just as with object-level security, we recommend to configuring field-level security using permission sets and permission set groups.

The graphic here shows how you provide field-level access through a permission set.

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. Record-level security is often referred to as the Salesforce sharing model, or just simply “record sharing” or “sharing”.

Salesforce provides five ways to share records with others and access others’ records. You start by configuring org-wide defaults, to lock down your data to the most restrictive level. Then you use the other record-level security tools to grant additional access to selected users when needed.

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

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.

Note: Ownership can also be granted to groups of users, for instance, queues. But we’ll not be covering that in detail in this blog post.

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:

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

3.2 Record-level-security: role hierarchies

Typically in an organization, different job roles have different record access requirements. Normally job roles are sorted in a hierarchical way: users with a higher role should have access to records to which users in lower roles have access. Note that a role hierarchy rarely maps to an org chart. It really maps hierarchies of data access. Salesforce provides an easy way to share records with managers and represent a role hierarchy. 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, an admin might set a criteria-based sharing rule to share with Maria all accounts whose billing city is San Francisco.

3.3.2 Guest user sharing rules

A guest user sharing rule grants read-only record access to unauthenticated guest users. It is really a special type of criteria-based sharing rule. Read more about them here.

3.4 Record-level-security: manual sharing

Manual sharing 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: Maria has noticed that premium accounts have a Customer Service lead user assigned to them. She’s realized she’s spending a lot of time manually sharing with this user. She reached out to the admin team to make that sharing automatic, but this won’t work with sharing rules, so they need their development team to write a trigger that performs Apex managed sharing. Learn more about Apex managed sharing.

Summary

Salesforce provides three layers of security with lots of flexibility to accommodate virtually any business need. Profiles and permission sets controls object-level and field-level access, with permission sets being our recommended tool to use. Permission set groups are the next generation way to model job roles instead of profiles.

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.