Record Level Security in Salesforce

To implement a more precise control over the data access, Salesforce allows particular users to view specific fields, that are associated with an object. Record access specifies which individual records can be viewed and edited by the users, for each of the objects that the user profiles can access. Before even determining the record level security we should consider certain factors. You need to ask, should the users have free access to all the records or a set of records. If the users are accessing to set of records, are there any rules defined to access them?

Use Case

Assume that you have created a new profile called Contractor, to provide the object-level permissions to the Contractors, required by them. However, you enforce a restriction that doesn’t allow the contractors to delete the objects related to the contractor. But, they can create records, edit a record, and even view the records associated with contractor objects. The questions come again, shall they have access to all the records or a specific set of records, or a subset of records. This leads us to two important learnings. Firstly, record level permission is always evaluated in accordance with the filed level permissions, object-level permissions, and record level permission. This means that record level permission is not independent. Secondly, since the record level permission is not independent, there might be conflicts between the object level permissions and record-level permissions. In the case of conflict, the most restrictive permission will be applicable. That means the stronger permission will override the weaker permission.

This leaves us with the fact, even if a particular profile has been provided create, edit, and view permissions on the contractor object, these profile permissions can easily be restricted by a record level permission.

Controlling Record Level Access

Record level access can be controlled in four distinct ways. We have ordered them below, the access level as we go in the ascending order to the last item. This means the first item will be more restrictive, while the last one will be least restrictive with more access. We use the OWD to provide a higher level of restriction to the data, while manual sharing gives a higher level of access.

1. Org Wide Default (OWD): OWD specifies the default access level for the users, to access the records of the other users.
2. Role Hierarchies: This is role-based access, and can be incorporated with OWD to ease out the access. For example, a manager needs to access the data of subordinates. In this case, each role defined in the hierarchy defines the level of access within the Org.
3. Sharing Rules: Sharing rules enable default exceptions to OWD for a specific group of users. We can apply the rules readily to a public group. This gives access to the users for accessing records which otherwise they cannot access. Thus giving a higher level of access, in comparison to the last two options.
4. Manual Sharing: In manual sharing, the record owner themselves can provide access to other users, who don’t have access.

If we look at the pyramid above, we can see that manual sharing has got the most eased out access, while OWD has got the most restrictive access. In other words, as we go down the pyramid, the record level access gets more restrictive.

The security controls are based on the principles given below.

• The user’s profile determines their baseline permissions.
• Assigned permission sets are based on the profile.
• OWD determines the permission to other records that are not owned by the user.
• Sharing rules can be used for expanding access to the additions user groups. As from the pyramid, we can already see that the sharing level provides the maximum level of access.