Salesforce Security Model – Explained
Keeping the information secure is very important no matter whom information is this. The information may be yours, your customer or your customer customers. So in this post, we will discuss the security model in detail.FLS and RLS are one of the most confusing topics 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 provide 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)
- Profiles
- Permission sets
RLS (Record Level Security)
- OWD
- Role Hierarchy
- Sharing Rules
Security Supporting Components
- Groups
- Queues
- 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.
- 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 😉
Hi, there is one question, how to make file private to the user only?
Hi Sunil,
To make a file private, follow the below steps: –
1 – Click on File Tab -> Locate the File that you want to make private -> Click on Down Arrow new to File -> Sharing Settings
2 – Provide No Accesspermission Under the Permission column next to User/Group
Note: – 1 – To make a file private you must be either the owner of the File or You have Modify All Data Permission @Profile Level.
2 – When the user uploads a new file by default it is not visible to other users.
Also, Please follow the below links for more information: –
https://help.salesforce.com/articleView?id=collab_files_change_permission.htm&type=5
https://help.salesforce.com/articleView?id=collab_files_make_private.htm&type=5
Thanks,
Sfdcpanther
I think using with sharing class also enforce FLS along with record level access?
What does normal class do if we simply use
Public class Classname{
}
how will it behave in the security point of view?
No. with sharing keyword only enforce the record level access.
If you do not use with sharing with the class then by default it will run without sharing and will not enforce the record level access or sharing rule the class will run with the admin record level access.
Hope I am clear to you now 🙂
Regards,
SFDCPanther