The security model provided by Salesforce is quite comprehensive and flexible. This gives a lot of room to handle real-world business scenarios for industries with varied backgrounds whether it is health, technology, finance and so on. This helps companies secure data at different levels within their internal hierarchy as well as from outside. Salesforce also allows various sharing tools to open up access to data based on various criteria as defined by the users.
In Salesforce, data is stored in three structures: Objects, Fields and Records and uses object, field and record-level security respectively to handle the data accessibility in these structures.
OBJECT-LEVEL SECURITY :
The First Layer of the security model is the Object Level Security. Now before allowing access to a particular user, Salesforce checks whether the user has the right permissions to access that object. Salesforce controls Object-level access through two configurations :
1)Profiles2)Permission Sets
Profiles :
Profiles in Salesforce, control access to object-level and field-level security among other things like apps, tabs, and so on. These are akin to the base permissions that you want to give to your user. If you have a Sales team and you want to give some general permissions to all of them, you can make use of profiles. You can only assign one profile to a single user.
Permission Sets :
Permission Sets are basically additional access that you can grant other users over their profiles( if the profile does not allow access to that object). You can assign multiple permission sets to a user. You can assign Read/Write permission set to a particular user with the Sales profile which gives him/her access to, say, lead Object which was not available for Sales profile. In this way, you have given access to an object to a particular user and not every user of that profile. Point to note here is that you can give additional permissions to a user but you cannot delete or reduce access using the permission sets.
FIELD-LEVEL SECURITY :
Now, once you have decided on your Object-Level Security, you need to consider Field-Level Security (FLS) which manages access to various fields of an object(Second layer of Security). Profiles also control the FLS access and an admin can provide read and write permissions for individual fields or hide them completely as well.
RECORD-LEVEL SECURITY :
In Salesforce, on a record level(third level of security), you only have access to records that you own (which normally are the ones that you created). But since you can be a part in the company hierarchy, there might be people reporting to you and you might yourself be reporting to someone. In such a scenario, there are five ways in Salesforce you can extend access to certain records to others and get access to certain records which otherwise would be inaccessible. The five types of Record-Level Security, also known as Record Sharing Rules are :
Organization-wide Sharing defaults (OWD): OWD control the default behavior of how every record of a given object is accessed by users who do not own the record. It sets the fundamental security around your object records. If you want someone to have read/write access to a single record and not others, you have to make OWD on that object as private and then start opening up records using other sharing rules we are going to talk about later.
Role Hierarchies: Every company has a certain hierarchy internally where almost everyone reports to someone superior to them and has someone reporting them so as to form a tree-like structure. Users in Salesforce are only assigned one role at a time. The crux of this sharing model is that if I create certain records, apart from me, anyone who is above me in the role hierarchy can see them as well. But you cannot see any records of those users who have the same roles as you do. For this, you need to make use of Sharing rules which comes next.
Sharing Rules: From the Role Hierarchies model, we saw that we can share our access to records upwards. But what if we want to share rules laterally? For this, Sharing rules provide a way to share records laterally and in an ad-hoc fashion based on ownership (Ownership-based sharing rules) or based on certain values in the fields of the record(Criteria-based sharing rules).
a) Ownership-based sharing rules let admins share records based on role, role-and-subordinate, and public group ownership. Here we can share records based in a certain role, or share them with a particular role and the subordinates which means you also have access to the records which are owned by users whose roles are under the role of the user you are sharing this rule with and finally with public groups where you group some particular users together and allow them to share records.
b) Criteria-based sharing rules let users access records based on the value of a field in a record, irrespective of who owns the record. This can be used when you want to allow certain or all users in your org to have access to Opportunities that have been closed-won.
4) Manual Sharing: Manual Sharing allows you to share records manually on a record by record basis. This permission is accessed through the Sharing button on the record details page, and lets users share any particular record with others (This sharing feature is only available if the OWD is set to private or public read-only. You won’t need it otherwise).
5) Apex managed sharing : In instances when you cannot share your security settings via User Interface, you need to write Apex code to do so. Here you can ask the admins to create an Apex managed sharing rule or make one yourself if you are an admin.
Just to sum up, the first thing you need to do is have the user access to the object through profiles and permission sets as Object-Level Security. Then Field-Level Security is used to allow access to individual fields within an object. Also, we have five types of record-level security: org-wide defaults, role hierarchy sharing, sharing rules, manual sharing, and Apex-based sharing. These sharing models are used to set manage access to records and even extend access of individual records to those users who do not own these records.
