Access Grants : Record Access Calculation in Salesforce

Salesforce always check record accessibility whenever user view record in order to maintain data visibility as per sharing settings specified in org. Record access can be granted based on role hierarchy, sharing rules, in-built sharing etc.

Imagine a large scale implementation which involve large number of roles, sharing rules and customized apex managed sharing. In order to determine user access for record by considering  this scenario will take lot of time and will result in performance issue.

In order to avoid this kind of performance issues, Salesforce doesn't calculate record access in real time but it calculate record access whenever any configuration change occurs and store that information. This helps in calculating the record access in real time instead of traversing all hierarchies, applying all sharing rules or analyzing other available record sharing mechanism.

Access Grants

Salesforce uses Access Grants in order to identify how much access user have to object records. This comes into picture only when OWD for object is either PRIVATE or PUBLIC READ ONLY.
Access Grant also specify the sharing tool (like sharing rule, teams,roles etc) responsible for providing record access to user.

There are four types of access grants used by Salesforce:

• Explicit Grants

Salesforce uses explicit grants when records are shared directly to user or groups. Below are few scenarios which are considered under this:

1.  Teams : When user is part of account, sales or case team.
2. When user or queue becomes record owner. All users under that queue get access to record.
3. When record is shared by using sharing rule, apex manage sharing and manual sharing.
4. When record is shared with user or queue based on assignment rule or territory rules share record with territory. All users under that territory get access to record.

Note: If you are using Enterprise Territory management, user can not share record manually to territory and while using sharing rules or apex managed sharing, record can not be shared with territory groups.

• Implicit Grants

This is called as built-in sharing in salesforce. These are predefined record sharing behavior for  Sales, Service and portal applications. For example:

1. User can view parent account record if they have access to child opportunity, case or contact record.
2. If user has access to parent account, then they can access child opportunities, cases and contact records.

• Group Membership Grants

This grant comes into picture when user, personal or public group, queue, role or territory is a member of group that has explicit access to record. So it means all user users or group which are part of public group with which any record is shared, the all group members and members present in sub-group  will get access to records.

• Inherited Grants

This comes into picture when user get access to records because of role hierarchy, territory hierarchy or inherit access through group hierarchy.

Sharing database Architecture

Salesforce store access grants in three types of tables:

• Object Record Tables

This table indicate which user, group or queue own each record.

• Object Sharing Tables

This table store information like which record is shared with which user or group either by apex manage sharing rule or declarative sharing when object OWD is not PUBLIC READ/WRITE.

This table store data that supports explicit and implicit grants.

• Group Maintenance Tables

This table store data that supports group membership grants and inherited grants. 

Declarative Sharing Vs Apex Managed Sharing

Force.com platform provides declarative sharing option which are easy to configure and meets basic data sharing requirements.

Different declarative sharing options

• Record Ownership

Record owner will have read, edit, delete, share and transfer access.

• Teams

Account teams, sales team and case team allow group of users to have access to different account, opportunities and case records.

• Role hierarchy

This allow users in higher role to have same level of access to data which users have in lower hierarchy.

• Sharing rules

You can create owner based or criteria based sharing rules in system which will open up the record access to users. Records can be shared to public group, roles,roles and internal subordinates, roles internal and portal subordinates etc.

Sharing rules also allow to share data with external users. The default external access level must be more restrictive or equal to default internal access level.

For example, if external sharing default is set to Public Read-Only for custom object, then valid internal default settings will be Private and Public Read Only.

• Manual Sharing

Manual Sharing is also known as User Managed Sharing. This option allow user to share record manually with another user or public group, portal roles, portal users, roles, roles and internal subordinates, roles internal and portal subordinates etc.

Remember if record owner share record manually with another user and later on record owner changes, then manual sharing record will be deleted.

Apex Managed Sharing

This allows developers to share records by using apex code. This is also known as "Programmatic Sharing". Object share records can be created for standard and custom object but custom sharing reason can be defined for custom object only.

For example, if we have to share a record with a user specified in lookup field, then you can use trigger to create record in share table to provide access. 

Valid access level for records are Edit/ Read.

If OWD for object is either Public Read only or Private, then share table will exist for that object. You can create record in that share table to provide access to any user. Below are 4 fields you need to specify in order to create record in share table:

• ParentId : 15 digit or 18 digit id of record which you want to share.
• UserOrGreoupId : User id or group Id
• Access Level : Edit or Read. This field must be set to an access level that is higher than the organization’s default access level for the parent object.
• RowCause : You can specify the reason for sharing record. First define sharing reason for custom object. For standard object, you can specify Manual.

 You can not update ParentId field.

You can share record with same user or group by using different sharing reasons.

Consideration while using Apex Managed Sharing

• If record owner changes, then sharing created through apex managed sharing (if row cause is not manual and uses custom sharing reasons) are maintained but if user share record manually, then record sharing will be lost if owner changes.
• User with "modify All Data" can only add, edit or delete records in share table.