PREFACE: This post is part of the Zero to Hero series.

One of the largest and most important topics of Salesforce tends to also be one of the more confusing and daunting topics – Salesforce Security. There are multiple elements to Salesforce security from user setup and record access to login access and org policies. Each of these areas of Salesforce security is crucial to ensuring that your org and companies data is secure.

This chapter of the Zero to Hero series will focus on each of the elements of security, starting with record access.

Record Access Overview

To start, let’s look at the big picture and learn about the elements at play. I like this image from Salesforce, which outlines the elements of record access in Salesforce.

This chart starts with Organization-Wide Defaults, or OWDs, which are the most restrictive permission in Salesforce, and moves to the least restrictive permissions on the far right-hand side with Manual Sharing. To get started, let’s break each of the security elements down and explain each one.

Organization-Wide Defaults (OWDs)

OWDs are set at the organization level and determine the base level record access for everyone in the org (with the Salesforce Administrator being the exception to the rule as the Salesforce Admin always has access). Every object in Salesforce has an associated OWD.

Salesforce defaults every new org to a very public sharing model with OWDs set to Public Read/Write for every object. Depending on the security and record access needs of the organization, these company-wide defaults may need to be scaled back. In the organizations I’ve worked for in the past, the default OWDs of Public Read/Write were never used for every object.

So, how do you know what OWD access level is appropriate for the org? Think about who will be accessing the data and think about any exceptions. A public org is not uncommon, but if there is just one exception to that rule, you’ll need to restrict OWDs to the most strict level of Private and open access to users leveraging the other tools.

For example, let’s say that everyone in the organization should have access to all records in Salesforce. If that’s the case, you’ll choose either Public Read/Write or Public Read-only depending on your preferred access level. Now let’s say that it dawns on you that there is just one specific user who shouldn’t see every record in Salesforce – now what? Well, because of that one user or use case, you MUST fully restrict access to Private and use the other sharing elements to grant access back to users who need access.

It’s extremely important that you’ve thought through every business case to determine the appropriate level of OWDs for the organization as it sets the foundation for all of the other sharing methods used.

Role Hierarchy

Users are assigned a Role and Profile in Salesforce. These designations determine what a user has access to and what they can do with that information. The concepts of Role and Profile tend to confuse new Salesforce Admins, so here’s my simplified explanation of roles and profiles.

Roles determine what data a user has access to. Profiles determine what a user can do with the data they have access to.

Now, there’s more to roles and profiles than that, but this super simplistic definition of roles and profiles helped me understand the difference as a new Salesforce Admin.

Notice in Figure 1 that the Role Hierarchy grants vertical access to records. By default, data access flows up the role hierarchy. The higher up in the hierarchy, the more data you can see by default. Let’s get a visual representation to help clarify the point.

Access via the role hierarchy flows up. So, in the example hierarchy shown in Figure 2, the Customer Care role, which is equal to Product Management, Operations Support, and Information Technology, would be able to see every record below it regardless of ownership. That includes records owned by someone in the Event Coordinators & Meetings roles.

The same is true for the Operations role. Any user in the Operations role can see any record owned by anyone below them in the role hierarchy which, in this example, would include everyone in the organization.

An org’s role hierarchy is a critical backbone to not only Salesforce record access and security, but also enables additional functionality that can impact groups, list views, reporting and more. That’s why it’s important to have a well-built role hierarchy.

RELATED POST: How to Build a Rock Solid Role Hierarchy

Sharing Rules

Sharing rules work in conjunction with the Role Hierarchy and the OWDs to further open access to users. You’ll notice in Figure 1 and Figure 2 that Sharing Rules open access laterally in the org. Remember, OWDs restrict access for everyone in the entire org, and the role hierarchy opens access virtually by default, but not horizontally across the org.

Take a look at Figure 2 again and pay attention to the yellow box. If an orgs OWDs are restricted to Private, then users in the Event Coordinators & Meetings role can’t see records owned by Customer Care Representatives or any other role across the organization. Sharing Rules open access to these roles allowing data to be shared laterally.

Manual Sharing

Manual Sharing is the most flexible of all sharing and, if enabled in the org, allows the record Owner, and anyone above the record owner in the Role Hierarchy to share a single, specific record to a person or group.

User Profiles

While user profiles don’t play a specific role in how data is shared in the organization, they do play a critical role in providing very granular level access to records. Think of OWDs and Sharing Rules as Phase 1 of the sharing process and Phase 2 is the creation and maintenance of user profiles.

As we discussed earlier, Profiles determine what a user can do with the data they can see as granted by OWDs, Role Hierarchy, and Sharing Rules, so it’s important not to ignore profile management as part of the record access process.

CRED

CRED stands for Create, Read, Edit Delete and is a profile setting that allows users these specific permissions for objects they have access to. Every user profile can have a specific CRED for each object, based on how the user will be interacting with the record itself. It should be noted that a user could have access awarded to them through the sharing settings, but if they don’t have at least Read access to the object, they’ll be unable to see related records.

Field Level Security

Once CRED is defined for a profile, Administrators can also restrict access at the field level as well. This super granular level of access could make a field read-only, or completely hide the field from the user.

Let’s say that all users have access to a Finances object, but only a specific group of users should have access to the credit card field which houses a client’s credit card number. Field level security won’t restrict access to the object (that would be defined in the Sharing Settings discussed above), but we can restrict access to the credit card related fields for the appropriate profiles using field level security.

If a field is not awarded to a profile, the users will not know it exists at all.

System Level Permissions

Profiles also determine system level permissions awarded to specific users. For example, if a group of users shouldn’t be able to create reports in Salesforce, a System Level permission can be removed to prevent users with that assigned permission to generate reports.

While most default system level permissions are maintained, Administrators can restrict access to specific features of Salesforce through the profile. While these system permissions don’t directly impact record access, they do impact the usability of Salesforce. Changes to system permissions should be considered carefully.

Permission Sets

In the past, Salesforce Administrators needed to create on profile for every access combination presented by the business. This meant that one unique profile may have been created for one specific user to award them the appropriate level of record and system access needed. Permission Sets removed that requirement and allowed Administrators to award one-off permissions to specific users.

It’s important to note that Permission Sets are not assigned at the profile level. Think of Permission Sets as very specific profiles that can be awarded to users in a many to many relationship. Any one user can have any number of permission sets assigned.

Permission sets can contain object and record level access or system permissions and can be awarded to a single user. As a result, they drastically reduce the number of profiles an org needs to create while allowing flexibility to the org.

Additional Resources

Record access is a big topic, as mentioned before. There are additional resources throughout the community which go into more detail or explain each element in a little bit different language. Here are some of the resources I’ve found useful over the years.

• User Management – Trailhead
• Data Security – Trailhead
• Salesforce’s Who See’s What series on YouTube
• ShellBlack Whiteboard series on YouTube
• Salesforce Help & Training Documentation