RLS (Record Level Security)
Security Supporting Components
(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.
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 are 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 color = 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.
How? Provide Object level and Field level access to Salesperson profile. Make OWD for Account Object to private. With this salesperson 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!!
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 fulfill the requirement is to put Director role in the Top Hierarchy. Simple!!
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.
How? Share the records owner by Role ‘Sales Operations 3 ’ with role ‘Sales Manager 3’
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 arises 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 to cover the same.
There is a very common interview question and most of the people failed to give a satisfactory answer to the interviewer that is: – What is the difference between the Sharing and with Sharing keyword?
Answer: – The simple answer to this question is that if Apex Class is declared with sharing keyword and in the class user is making SOQL to any object records then before making the soql to the object system will check if the user has access to those records or not no matter user is owner or shared by the sharing rule, manual sharing or Apex sharing.
On the other hand, if Class is declared with without sharing keyword then the class will run as administrator and as admin by default has all access it will return the records.
Note: – In the above, most of the people think that using with sharing class will be forced to check the FLS and Object level security. But sharing rules always deals with records not object and fields.
Keep secure your information and keep learning 🙂
Sharing is caring 😉