Quick classic question? Why is there a need to control access at the record level when it's already restricted at object and field level? Why does it even matter? Friends, I have always wondered about this. But let me tell you, when we talk about object-level security, we focus on restricting the CRUD access on objects. Let's assume there is a box, so it's precisely like whether you can see the box or open it or see what's in it, an object is like a skeleton.
Similarly, when we come onto FLS, it's about whether you can insert the data in that field or does it even privilege you to view itself on the layout. But a record is a wholesome amount of data; when we try to control the readability or editability of a record, this is where record level security comes into the picture. Remember, these security control levels do not work individually; they are all combined packages and will enforce the strictness altogether, meaning the most restrictive among all three levels of security is flashed in the whole environment.
Record-level access is controlled in four ways. The inverted triangle represents the pattern of accesses opening up. Org-wide defaults are for locking down the data to the most restrictive surface. Still, as you can see, salesforce also privileges the other record-level security tools to grant access to the selected users, as needed.
Our previous blogs mentioned configuring object-level and field-level access for profiles and permission sets. Let's look at the details of the various record-level security controls.
OWD - Organization-Wide Default
Org Wide Default is the baseline of security; to restrict the data, one should set org-wide defaults to either private or public read; the default is public read/write. Org-wide defaults fail to grant users more access than through their object permissions. Ok, let's first ask ourselves a few questions when we are setting the org-wide default for the users in the org -
1. Identify the most restrictive user of this object.
2. Will there be an instance of this object that this user shouldn't be allowed to see?
3. Will there be an instance of this object that this user shouldn't be allowed to edit?
Based on the above three tasks, one can set up the restrictions on the object's record. Let us understand what types of org-wide default settings are available.
1. Private - Only the record owner, and those positioned above that role in the hierarchy, can view, edit, and report on those records.
2. Public Read Only - Everyone in the org can view and report on records. However, only the owner, and users above that role in the hierarchy, can edit them.
3. Public Read/Write - Everyone in the hierarchy can view, edit, and report
4. Controlled by Parent - A user can conveniently view, edit, or delete a child record. If they can perform that same action on the record, it belongs to(Parent).
When there is an org-wide sharing setting for an object set to Private or Public Read Only, you can grant users additional access to records by setting up a role hierarchy or defining sharing rules. Sharing rules are used to give additional access more than role hierarchy. As I have already mentioned in the previous security blogs, control is for maintaining the data invariably. Some users in your organization will be privileged to see others' data and act upon it accordingly. Let us know how to open up the org-wide default restrictions.
How to open up record-level access
Role Hierarchy - First of all, let's be very clear this type of access is only allowed when the "Grant Access Using Hierarchies enabled" checkbox is set to true(its default true btw) on your share settings page from where you can set the OWDs. If the administrator sets it to false for the particular object, the role hierarchy will not play. But there is a fascinating fact as well: even if Grant Access using Hierarchies is deselected, users who have "view all" and "modify all" object permission or has "View All Data" and "Modify all data" system permission will be able to peep in your record. Now how this role hierarchy works, when you set the OWD of any object as "Private" and if "Grant access using hierarchies" is enabled, then your seniors and your subordinates can view your records quickly, now there's a trick. All roles above you in the hierarchy can do anything with your data. They can - read, edit and delete, but your peers can only read or edit your data.
This is the base from where the record-level access starts opening up; this is by default enabled by the salesforce system. We will see more ways to open up the record level access, shown in the next blog. Till then, stay tuned.
