Salesforce Security, What Every Developer Must Know. - El Toro - Find articles about Visualforce, Apex, and Salesforce in general

Print Preview

Salesforce Security, What Every Developer Must Know.

Security in Salesforce is very complex with a lot of moving parts, which is a very good thing because you have absolute control of the data, but it’s challenging to learn because of it’s complexity. Hopefully this blog helps you understand it a little bit better.

The base of the security is the user, who must be logged in before they can see any data. This holds true even for sites, for example, where your customers can have access to the data you expose, without asking them to log in, because you configure the security for a guest user acting as your customer.

Going back to the user… When you configure them, you will assign a profile and optionally some permission sets, which control two of the three main parts of the security model: CRED (CRUD) and FLS.


This permission allows the user to Create, Read, Edit and Delete records from an sObject (a table in Salesforce terms).  Sometimes you will find this named CRUD because Edit is called Update.


This permission allows the user to View and Edit fields from the records he can view.

Wait, you said these were two of the three main parts what’s the third part? I’m glad you asked, let’s talk about…

Sharing Model (Record Access)

The third main part of the security model controls Read and Write access to the individual records in the database.

Of these three parts, which one do you think is more important? Would you say is CRED? FLS? Record Access? Think about a tripod, which of the three legs are more important? Exactly!

This brings me to a story of the day I finally got my driver license. It was a very nice day on summer; I had finally completed the practice test, which took me several tries. I had a card with my name and picture, which told the world that I drive any car… not just my dad’s car with him next to me. I was very excited that day, but things got even better when I came out of the DMV and I saw a red shiny Ferrari park right there. I could not believe my luck. I wanted to drive it! I tried to open the door, but it was locked. So I tried a bit harder to open the door, and the alarm went off.

A police officer came out of the office and asked me “What are you doing? You can’t drive that!” I very politely pulled out my driver license, show it to him and said “Excuse me officer. This is my driver license; it has my name and picture, right? It gives me access to drive a car, right? That’s a car, right? So I’m going to drive it!”

Then he asked me “Do you own that car? Do you have permission from the owner to drive it?”, to which I simply responded “but this is a car and I can drive any car with this license, right?”

That day, I learned that being able to read a record (CRED) does not mean that I can read any record (Sharing Model).

This sounds simply right? So why did I say it was complex? Well, we are just starting here… The most complex part is the Sharing Model because there are many features that affect whether a user has access to a record or not. The possible options here are: No access, Read access, Write Access and Full Access.

What is Full Access?

Full Access, sometimes called ownership access, gives the user access to read, write, transfer ownership (changing the owner field), share (let other users have read or read/write access) and delete the record.

When is Record Access Ignored?

Actually never! But there are some features that could affect the record access, and override some of the controlling features.

How Do Profiles / Permission Set features Affect Record Access?

First of all, the profiles/permission sets control CRED and FLS, but there is a setting that controls the Sharing Model. Actually there are four settings called:

  Access Given
View All Data Global Read
View All sObject Read
Modify All Data Global Full Access
Modify All sObject Full Access

* All

These two permissions (View All and Modify All) are given for each sObject independently and control only the records in that specific sObject. You may give this for some sObject and not for other ones.

* All Data

These two global permissions (View All Data and Modify All Data) are given at the profile / permission set level and control every record in the ORG, regardless of the specific object. Administrator should have this setting, allowing them to configure any record in the database.

View *

These two permissions give read access to records. As mentioned before they can be applied to either a single sObject or to whole database. View All gives read access to all the records of the sObject to which it’s applied, but View All Data gives read access to every record in the database.

Modify *

These two permissions give full access to records. As mentioned before they can be applied to either a single sObject or to whole database. Modify All gives full access to all the records of the sObject to which it’s applied, but Modify All Data gives full access to every record in the database.
So users with these permissions do not follow the settings configured for the normal users, because their access gets enhanced and overriding with their profiles or permission sets.

How Do Master-Detail Relationships Affect Record Access?

Although technically this is not a way to control the Sharing Model, when you create a Master-Detail relationship the detail records inherit the record access from their masters. Whoever can read a master record, is automatically given read access to the detail records. When you configure a Master-detail relationship, you can also specify what’s the minimum access required on the master record (read, read/write) to create, edit, or delete related Detail records.

The sObjects that are not details in a Master-detail relationship can have other features controlling the record access. The next section lists the main features controlling record access, and for simplicity when I say “any sObject”, I really mean “any sObject that’s not the detail of the Master-Detail relationship” for simplicity.

Which Features Control Record Access?


One of the standard fields for any sObject is the Owner field, which is defined as a lookup to a User or a Queue. The user who owns the record, or any of the users that belong to the queue who owns the record, has full access.


A queue is a collection of users for the purpose of owning (having full access) a record. Cases and leads are the only standard objects that can have queues, but you can configure a queue for any custom object. Let me explain with an example how queues are used.
When I first joined Salesforce in 2009, I started working as a Developer Support Tier 2, and there was a queue with that name. Whenever a customer called, an agent on the Tier 1 would answer the phone/email and create a case with the details for the customer. Since the agent had created the case, he was the owner and he had full access to that record. Most cases he could not solve the issue and he would “escalate the case to Tier 2”. Basically that meant, that he would change the owner of that case record to the queue named Developer Support Tier 2. When I came in the mornings, I could take a look at the records that had been put in the queue overnight and since I worked in Toronto, hours before my teammates in California, I could take a look at the easy cases - but don’t tell this to anybody ;-)
Anyways, once I found the cases I wanted to work I would change the ownership to me. This was possible because the case was in the queue and since I was a user in the same queue, I had full access to those records. Once I had taken ownership of that case, it was not in the queue anymore, and my teammates did not have full access on that case any more… so they could not change the ownership to them. I worked with the case until I closed it, or if it was a bug I had to escalate it to Tier 3 by changing the owner to the queue named Developer Support Tier 3.
So far we have seen what happens with users whose profile has View/Modify All [Data] or have a permission set assigned that gives them this access, but what about the other users? What permissions (if any) would they have? How could a user, who does not have View/Modify All [Data], get access to a record if they are not the owner?

OWD / Organization-Wide Defaults

The Organization-wide sharing defaults set the baseline access for your records. This basically defines the record access for those users that don’t have access through the profiles and do not own (user, queue) the record. You can set different options for different sObjects, based on your needs. You may want to have some sObject more public and other ones more private. For custom sObjects, the options that you can set are:

  • Private
  • Public Read Only
  • Public Read/Write 
  • Controlled By Parent (for details in a Master-Detail relationship)
Most standard sObjects have options similar to this, some standard sObject also have “Public Read/Write/Transfer”, but some standard sObjects use very different options. For example:

Calendar has these options: “Hide Details”, “Hide Details and Add Events”, “Show Details”, “Show Details and Add Events”
Price Book has these options: “No Access”, “View Only”, “Use”

Note that Salesforce, works with an “opening doors” security model. This means that if you open a door somewhere that gives access to a user, you will not be able to close that door with something different from what was used to open it. If you do not want that door open, then you do not open it. This makes handling the security easy and straightforward. For example, if you set the sObject as public Read/Write, then all your users will have read and write access to any record of that sObject at anytime. None of the features that control the Sharing Model can be used to restrict this access. If you do not want your users to have this much control, then you should set the OWD to private and then open it using other features.

Role Hierarchy

The best way to understand the Role Hierarchy is with this phrase: “My manager can do whatever I can do”. But before I go in details around this phrase, let’s take a look at the Role Hierarchy chart for an organization:

In many organizations, the Role Hierarchy is related to the Organization Chart, but it doesn’t have to be. Let’s take a look at few examples to prove this point:

  • Barry Cade who is part of the organization does not have a role (it’s optional field in the user table) and therefore is not part of the Role Hierarchy. But if an employee is not part of the Organization Chart, that user would be looking for work.
  • The System Administrators, who have Modify All Data on their profile, can do whatever anybody in the role Hierarchy can do (including Barry Cade), but the CEO, Joe King, does not report to him (although, he would love if it was the case).
It’s also possible that a manager does not see the records owned by their direct reports, if the role Hierarchy has been disabled for a particular custom sObject.

So let’s talk about the phrase I gave you earlier: “My manager can do whatever I can do”. Let’s decompose this phrase:

My manager

This may seem simple, but it requires some clarification, because remember this is not the Organization Hierarchy chart, so my manager does not have to be in a box higher than mine. For example:

  • May Q. Pay has one direct manager named Rob Mee, but in the previous Role Hierarchy chart there are two people in the role directly above May, Sue Mee and Rob Mee.
  • Although it’s not clear in the Role Hierarchy, Rob Mee is the manager of his sister Sue, but Rob can't do whatever Sue does.
So the phrase should be “Any person in a role higher than mine, can do whatever I can do”. Which brings me to the second part of this phrase.

Can do whatever I can do

Note that I am not just saying: “can view whatever I can view”, because the person in a role higher than the owner of the record, also has full access permissions to the record meaning they can delete, share and change ownership of the record.

You also need to understand that we are only talking about the Sharing Model, so this applies only to the record access. In order for a “manager” to do whatever the people below them can do, they must have at least the same CRED and FLS permissions. If my “manager” does not have Delete permissions in their profile, then they will not be able to delete my records (remember the tripod?)

How does this apply to a queue?

Good question, I’m glad you asked. Remember that any member of the queue has full access to the records that are currently owned by the queue. So that anybody in a role higher than anybody in the queue will also have full access. No matter how the people in a role below yours have access to the record, you will be able to do whatever they can do.

This is fine so far, but how could I let a user view my private record, assuming that he is not in a role higher than mine, and does not have View/Modify all (data) in their profile/permission set? Great question, I’m glad you asked. Let’s talk about how records can be shared. 

Record Sharing

The record sharing is composed of three main parts:

  • Managed Sharing
  • User Managed Sharing
  • Apex Managed Sharing
Let's take a look at each of these. Managed Sharing Managed Sharing has these parts:

  • Territory Hierarchy
  • Teams
  • Sharing Rules

Territory Hierarchy

Salesforce Territory Management provides a way to grant access to accounts based on characteristics of those accounts. The territory hierarchy enables users to view data shared to their territories or territories below them in the hierarchy.


Account Teams, Sales Teams and Case Teams provide access to a group of users who work on a particular account, opportunity or case.

Sharing Rules

Sharing rules are ways to make automatic exceptions to your organization-wide sharing settings for defined sets of users or sets of records.

As shown on Step 2, the type of the sharing rules can be either: Owner Based or Criteria based.

  • Owner Based Sharing Rules: These sharing rules grant users within a given public group or role access to records owned by a specific group of users.
  • Criteria Based Sharing Rules: These sharing rules gran users within a given public group or role access to records based on field values within those records.

So why is it called “Managed”? Great question, I’m glad you asked. Basically, when a something changes the record access is recalculated. What type of changes? • Record changes owner • User leaves or joins a team or a territory • Record values that affect the criteria for the sharing rules

User Managed Sharing

User managed sharing, also called “Manual Sharing”, allows the record owner or any user with Full Access to a record to share the record with any user or group of users. When you share a record manually, you can only give read or read/write (not possible to grant other users Full Access) as long as it’s above the OWD setting for that object.

User managed sharing is removed when the record owner changes or when the access granted in the sharing does not grant additional access beyond the object's organization-wide sharing default access level.

This type of sharing is limited because it has to be done manually for each record that you want to share, but in order to share it with other users automatically you can use Sharing Rules or Apex Managed Sharing.

Apex Managed Sharing

When the user shares a record using Manual Sharing, an entry is created in a special sharing table (AccountShare, CaaseShare, or CustomSObject__Share). You could also write some code in Apex or the APIs that performs a DML operation in this table, and that’s called Apex Managed Sharing. This type of sharing is maintained across record owner changes.

How Can Users Be Grouped?

In Salesforce, there are many ways that you can group users to control their securities together.


This collection of users control many features, but with regards to security, it controls CRUD, FLS and View/Modify All (Data) permissions.

Public Groups

This collection of users is to apply to Sharing (Sharing Rules, User Managed Sharing, Apex Managed Sharing). It also applies to Folders, Documents, Reports, Dashboards, Emails and List views


This collection of users receives Full Access for those records that are owned by the queue.


This collection of users is for working with the Role Hierarchy and for providing access to the records where “my manager can do whatever I can do”

comments powered by Disqus

© El Toro . IT @ 2013
Andrés Pérez