Salesforce Security – Record Access

1. What is Salesforce security?

Salesforce is built with security to protect your data and applications. You can also implement your own security scheme to reflect the structure and needs of your organization. Protecting your data is a joint responsibility between you and Salesforce. The Salesforce security features enable you to empower your users to do their jobs safely and efficiently.

2. Features of salesforce security

The Salesforce security features help you empower your users to do their jobs safely and efficiently. Salesforce limits the exposure of data to the users that act on it. Implement security controls that you think are appropriate for the sensitivity of your data. We’ll work together to protect your data from unauthorized access from outside your company and from inappropriate usage by your users.

3. Levels of Data Access

You can control which users have access to which data in your whole org, a specific object, field, or an individual record.

Organization

For your whole org, you can maintain a list of authorized users, set password policies, and limit logins to certain hours and locations.

Objects

Access to object-level data is the simplest thing to control. 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 profiles to manage the objects that users can access and the permissions they have for each object. You can also use permission sets and permission set groups to extend access and permissions without modifying users’ profiles.

Fields

You can restrict access to certain fields, even if a user has access to the object. For example, you can make the salary field in a position object invisible to interviewers but visible to hiring managers and recruiters.

Records

You can allow particular users to view an object, but then restrict the individual object records they’re allowed to see. For example, an interviewer can see and edit her own reviews, but not the reviews of other interviewers.

4. Record Access Overview

To start, let’s look at the big picture and learn about the elements at play. This image is 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.

a. 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.

b. 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.

c. 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.

d. 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.