- Permission sets
RLS (Record Level Security)
- Role Hierarchy
- Sharing Rules
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.
- Profiles are on the base level to grant field and object accessibility. No access means NO ACCESS. But exceptions are always there, with permission set you can provide FLS and OLS access to the specific user whom you have not provided access to profiles.
- When it comes to records visibility, OWD sets the baseline security for the object, however by default security is open and everyone has access to the record. You make it private results in restricted visibility. Important Note: Record Ownership is not affected with OWD, if you own the records you can see it anyways. One-liner: OWD Restricts the Access.
- Another important thing that plays a 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 the flow of information/data/Records. One-liner: More you are above more the access you have.
- OK, you have restricted the access to Object (OWD), your object records are safe and no one sees 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 come 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 a 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 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.
- Sales Person should not see each other Account records.
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!!
- 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 fulfill the requirement is to put Director role in the Top Hierarchy. Simple!!
- 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.
- Sales Operation 3 can view Sales Manager 3 records.
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 😉