Record Access Calculation
As there are many options for managing record level access, and as some of these options are affected by organizational dependencies, determining which records users can access can quickly become complicated. Rather than checking record access in real time, Salesforce calculates record access data only when configuration changes occur. The calculated results persist in a way that facilitates rapid scanning and minimizes the number of database table joins necessary to determine record access at runtime.
Access Grants
When an object has its OWD set to Private or Public Read Only, which is not the least restrictive option, Salesforce uses access grants to define how much access a user or group has to that object’s records. Each access grant gives a specific user or group access to a specific record, It also records the type of sharing tool: sharing rule, team, etc.
Salesforce uses 4 types of access grants:
Explicit grants:
Grants that occur when records are shared directly to users or groups. Examples:
- A user or a queue becomes the owner of a record, as in Salesforce each record should have an owner, and whenever a record is owned by a user or a queue, an explicit share is used to grant access to the record for the owner or queue.
- A sharing rule shares the record to a personal or public group, a queue, or a role.
- An assignment rule shares the record to a user or a queue.
- A territory assignment rule shares the record to a territory.
- A user manually shares the record to a user, a personal or public group, a queue, or a role.
- A user becomes a part of a team for an account, opportunity, or case.
- A programmatic customization shares the record to a user, a group, or queue, or a role.
Group membership grants:
Grants that occur when a user, group, queue, role, or territory is a member of a group that has explicit access to the record. So as you know by now, an explicit share is used to grant access to group via sharing rules, manual sharing or Apex sharing, because of which all members of a group are granted access using the group membership access grant. For example, if a sharing rule grants the “Sales group” access to the Acme account record, and Bob is a member of the “Sales group”, Bob’s membership in the “Sales group” grants him access to the Acme account record.
Inherited grants:
Grants that occur when a user, group, queue, role, or territory inherits access through a role or territory hierarchy or is a member of a group that inherits access through a group hierarchy. For example, if a user Alice has a role that is higher in the role hierarchy than the role of another user Bob, then Alice can access the same records that Bob can access.
Implicit grants:
Grants that occur when non-configurable record-sharing behaviours built into Salesforce Sales, Service and Portal applications grant access to certain parent and child records. Examples:
- Read-only access to the parent account for a user with access to a child record.
- Access to child records for the owner of the parent account record.
- Access to a community account and all associated contacts for all community users under than account
- Access to data owned by community users associated with a sharing set for users member of the sharing set’s access group.
Object Share tables store the data that supports explicit and implicit grants.
SELECT Id, ParentId, UserOrGroup.Name, AccessLevel, RowCause FROM AccountShareGroup maintenance tables store the data that supports group membership and inherited access grants.
SELECT Id, Name, DeveloperName, Type, OwnerId FROM Group
