A review of Record Level Security for Admins and Developers: Part 1

Security in Salesforce is a broad topic and the platform gives you the power so you can configure your system with a high degree of precision. As an Advanced Administrator and as a Developer, Salesforce lets you control permissions and access settings for users and groups of users. For example, you can control:

1. System security: Such as When users login and where they can login from
2. The sObjects they can see and the fields in each sObject
3. The records a user can access in an SObject table.

And so much more! For the context of this series, I’ll focus on Record Level Security (RLS) which in the world of salesforce is known as Sharing, the last question. It allows you to define if a user should have access to a record, and their level of access, if any.

So, why should you care about RLS/Sharing? It allows you to control the access to records in your sObject table and provide users the  correct rights they need (i.e. Read/Write) to the records that they should see. Additionally, it hides from them the records that they shouldn’t see. The latter is important because the records represent your company’s assets, knowledge, and relationships that they have invested in. With flimsy RLS, those assets are at risk. Why is this important? According to the Wall Street Journal, Sales people in the US have one of the highest turnover rates for all professions in the US.  So, imagine if your rep jumped ship to a competitor, and your Salesforce Implementation had lax RLS.  That’s a problem!Still not scared? Check out what Force.com MVP Chris Peterson said on the subject.

Salesforce gives you a number of tools and approaches to address this  issue and the common use cases. Additionally, it gives you the power to expand to more sophisticated rules via Apex.

This series will be broken down into the following parts:

1. The introduction and  background components
2. The tools to implement Record Level Security.
3. Common use cases & Debugging problems.
4. Sharing in Apex
5. Pitfalls of restrictive Record Level Security and some approaches to handle it.

If you’re interested in learning more about Salesforce Security, the kind folks at Salesforce wrote a thorough reference on the topic

 

---

Background: sObjects, Profiles, Permission Sets, Roles, and Types of Access

---

 

sObjects: What are they and how do they influence Sharing and Record Level Security?

sObjects have a lot of functionality in Salesforce, however for the context of this discussion, you can think of them as database tables, where each table is a collections of rows and columns. If we were to picture these in a table, the columns would represent your fields, and your rows the records of actual data. Getting back to Security in a table, I might want to control the following:

• Who can access the table?
• Who can access the columns?
• Who can access which rows?

Record Level Security / Sharing addresses the 3rd question and is the focus of this article.  The main driver of this is Roles, and a lesser extent Profile and Permission Sets.

Profiles/Roles/Permission Sets

Profiles and Roles represent two different groupings that each user is part of with different applications. For the context of this article, you should already be familiar with them however, I want to highlight a few key points on each.

Profiles  and Permission Sets  control object access; that is, can the user Create/Read/Update/Delete records on this object? They also control if the user can automatically view/edit all records on an object, or view/edit any records on every object.  From a security perspective, these permissions allow bypass your RLS, and are easy to set up as an Administrator. However, these should be used judiciously, as it can expose records that shouldn’t be exposed.  Additionally, every user needs to be assigned a profile.

OK, so say I grant a user Read and Write privileges on an object, what does that mean? That means he can read and edit records that he has access to. This is where Roles come in.

Roles in Salesforce control access to records. You want to see, and are analogous to users job roles. Roles are important because they drive much of the Record Sharing logic in Salesforce. Additionally, Roles can form public groups . As an implementation note, roles are optional in Salesforce, Profiles on the other hand are required.

Types of Access

On the platform, Salesforce provides four types of access when it comes to records. The access ranges from hiding the record from the user, to making it read only, to making it editable, to giving him full access.  In Salesforce terminology, here’s the types of access:

1. Private. This means that  the record is hidden to the user, and he can’t access a record in any way. In Database terms, he can’t Read /Edit/ Delete it.
2. Read Only –  This means that the user can Read the record, and Create related records to it.
3. Read/Write – The user can Read and Update  the record, and add related records to it
4. Full Access – The user can Read, Update, Delete the record. Also, he can transfer it, and  and manually share the record. This is typically the record owner and the person above them in the Role Hierarchy. More on this in the next article.

That’s a lot to chew on. In my next article, I’ll cover the tools to implement a successful sharing model.