Important Things to Consider for Record Access while Designing Large Scale Applications

As we already know through Organization wide default, record access to different users in system can be controlled. Apart from OWD, user can get record access through role, being a part of public group with which record is shared, territories etc. In order to control access of records, Salesforce maintain record sharing data and recalculate the sharing when any changes happen to role, territory, public group etc. For end user, changing user's role is simple operation but at the back end, Salesforce has to perform all record sharing recalculation based on user's new role.

Lets discuss all this in details. First we will start with Database Architecture. Salesforce maintains 3 types of tables as mentioned below:

• Object Record Table

These are the tables which stores records of specific object and indicate which user or queue owns each record.

• Object Sharing Table

If OWD of any object is public read only or private, the Salesforce create share table for that object.This table store information about record access for all users which is shared by explicit grant (shared with user or group) or implicit grant (built in sharing like access to child opportunity, cases if you have access to account record).

• Group Maintenance Tables

This table stores list of users or groups that belong to each group indicating group membership. Suppose a record is shared with group, then Salesforce check group maintenance table to identify which all users inherit access to that record (either through role hierarchy, group membership or through territories).

So when Salesforce has to find out that if user has access to record, then it perform join between three tables to identify record access for user. If user is owner of record, then it will display that record. If not it will check object sharing table and group maintenance table to find users access to record.

Salesforce Role hierarchy, public groups and territories are closely connected with sharing rules and security features. Suppose an user owns more than 10,000 records and now admin just changed this role. Now salesforce need to remove access to all these records for all user which are having higher role than user's previous role and need to provide access to all user's in higher role than new user's new role. So Salesforce has to recalculate the record access and sometimes it may take more time.

In order to handle these scenarios, Salesforce provide few tools which can be used to avoid these issues caused by user realignment either through roles, territory or public groups:

• Parallel Sharing Rule Calculation

Whenever admin changes user's role or change group membership or create, edit or delete sharing rules, then recalculation for record access happens synchronously. So when any of these changes affects access right to large number of records, the recalculation job take longer time. If any Salesforce perform any activity at this time like patch release or upgrade, then recalculation jobs get killed. In this scenrio, consider parallel Sharing Rule calculation. This will split the job in multiple threads which will run asynchronously and if Salesforce perform any activity, these jobs will resume after salesforce activity.

Contact Salesforce in order to enable this feature.

• Deferred Sharing Maintenance

Suppose you have rebuild the role hierarchy and group membership, the sharing recalculation may take significant time. In this kind of scenarios, you can enable deferred sharing which will allow admins to switch off of sharing recalculation and perform all role and group membership changes and then switch on sharing calculation. After switching on sharing calculation, admin has to start recalculation of all sharing rules for accurate user access rights.

Remenber deferred sharing doesnot stop sharing recalculation due to implicit sharing.

Contact Salesforce in order to enable this feature.

• Granular locking

Whenever any change is performed to roles or group, Salesforce locks entire Group membership table to protect data integrity. This will make impossible to perform group membership changes. Consider a scenario in which your users are facing frequent record locking error and restrict their ability to manage manual and automatic update at same time or degrade the group maintenance updates, then enable Granular Locking feature.

If Granular locking feature is enabled then system will lock portion of records instead of locking entire Group maintenance table. This allow multiple update simultaneously if there is no hierarchical or other relationship between the roles and groups involved in the update.

You need to contact Salesforce to enable Granular locking feature.

More Blogs>>: 

DYNAMIC APEX IN SALESFORCE
SOQL INJECTION IN SOQL
CUSTOM METADATA AND CUSTOM SETTINGS IMPLEMENTATION TRICKS
SMART TABLE USING ANGULARJS IN VISUALFORCE PAGE
REST API TUTORIAL FOR SALESFORCE
VISUALFORCE COMPONENT FOR RECORD STATUS BAR
DYNAMICALLY CREATING AND DESTROYING LIGHTNING COMPONENTS    
RAISING AND HANDLING CUSTOM EVENTS IN sALESFORCE lIGHTNING    
WHY TO USE DESIGN RESOURCE AND HOW TO ADD DYNAMIC OPTION TO DATASOURCE    
PASSING INNER WRAPPER CLASS TO LIGHTNING COMPONENT    
LIGHTNING COMPONENT FOR RECORDTYPE SELECTION FOR ANY SOBJECT