FLS and RLS are one of the most confusing topic when a person wants to implement the complex salesforce security Model, or when interviewer ask twisty security implementation questions. This post mainly covers the deeper understanding of salesforce security model with the practical examples which you can relate to the practical implementation or when someone tries to confuse you with the security scenario.

Before we take up security model scenario its must to know what all features and components salesforce provides to implement the security model, if you are not the beginner you must be aware of them. (Still providing links for reference)

OLS / FLS (Object Level Security / Field Level Security)

  1. Profiles
  2. Permission sets

RLS (Record Level Security)

  1. OWD
  2. Role Hierarchy
  3. Sharing Rules

Security Supporting Components

  1. Groups
  2. Queues
  3. Roles

(Note : If you are not aware or need more reference on above terms, please follow the links security-model , Difference between Role and Permission Sets. These Blog will give you overall idea with visual reference)

Before moving on to Security Scenarios, in depth knowledge and clearing the confusions are important. Let’s talk about them first.

  1. Profiles are on the base level to grant field and object accessibility. No access means NO ACCESS. But exception is always there, with permission set you can provide FLS and OLS access to the specific user whom you have not provided access through profiles.
  1. When it comes to records visibility, OWD sets the base line security for the object, however by default security is open and every has access to the record. You make it private results in restricted visibility. Important Note: Record Owner ship is not affected with OWD, if you own the records you can see it any ways. One liner: OWD Restricts the Access.
  1. Another important thing that play huge role in record security model is Role Hierarchy. Myth: Role Hierarchy is not necessarily your organization chart, it’s just the definition of role to manage up flow of information/data/Records. One liner: More you are above more the access you have.
  1.  OK, you have restricted the access to Object (OWD), your object records are safe and no one see each other records except the people who are in above role hierarchy. What Now? You need something to show the specific records to specific people. There comes the Sharing Rules and Manual Sharing (Using Share button on the record). One Liner: Sharing Rules are how to grant back record access single person or larger group of people.

If you need a key to keep your security model hands-on, keep one scenario always in mind. Consider your Org is a parking lot, With Profiles and Permission sets you can see or cannot see the Cars in the parking lot, means you cannot even own a car if you don’t have profile permission. On the other case that you can own a car but whether you can drive those all cars is managed by Sharing settings (OWD, Sharing Rule, Role Hierarchy). Means OWD private means you cannot see and drive the other cars except yours, while sharing rule having criteria “Car colour = Red” and Read/Write, you can see and drive your car and all other red cars in the parking lot. Role hierarchy? If you are the CEO of the company take any car from parking lot owned by your employees under you (This Sounds Awesome!!).

Now, when it comes to practical implementation and real-life scenario, let start picking the scenarios. Considering the below Org hierarchy model.

Security

  1. Sales Person should not see each other Account records.

How? Provide Object level and Field level access to Sales person profile. Make OWD for Account Object to private. With this sales person will be able to see records they own only.

Well, if we have role hierarchy also defined as per the above org role model, Sales Manager can see all records owned by Salesforce operation 1, Sales 1A,1B,1C roles. But Sales Manager 2 cannot see Sales Manager 1 and his below hierarchy records. Why? Remember OWD!!

  1. Directors able to see everything. (Not in a hierarchy yet)

How? You can do it via Sharing rules to give Read/Write access, putting Directors in Group and assign it to sharing rule. But more easy way to fulfil the requirement is to put Director role in the Top Hierarchy. Simple!!

  1. NA Account Approval Committee Needs access to Account with ‘Region = North America’

How? Here is what Criteria based Sharing rules work. Create one role with ‘NA Account Approval Committee’, or if these committee people are assigned with other pre-defined roles and you like to give them this access you have option to create a group of committee people. Create one criteria base sharing rule with Region = “North America” and select group to grant the access.

  1. Sales Operation 3 can view Sales Manager 3 records.

How? Share the records owner by Role ‘Sales Operations 3 ’ with role ‘Sales Manager 3’

 

Sharing Rule

I guess you might have query why not to put Sales Operation 3 to the same level of Sales Manager 3, like we did in 1st scenario? So, answer is to maintain the role importance. If any requirement arise that all sales managers can see each other records , sales Operation 3 will start seeing other sales managers records as well.

I’ll be covering more scenarios as I come across with more and will keep updating the same. Do comment and share if you have any scenarios and you like me cover the same.

Author: Lalit Arora

 

Advertisements