Group Membership Grants
Grants that occur when a user, personal or public group, queue, role, or territory is a member of a group that has explicit access to
the record. For example, if a sharing rule explicitly grants the Strategy group access to the Acme record, and Bob is a member of the
Strategy group, Bob’s membership in the Strategy group grants him access to the Acme record.
Inherited Grants
Grants that occur when a user, personal or public 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.
Implicit Grants
Grants that occur when non-configurable record-sharing behaviors built into Salesforce Sales, Service, and Portal applications grant
access to certain parent and child records. For example, with this default logic, sometimes referred to as built-in sharing, users can
view a parent account record if they have access to its child opportunity, case, or contact record. If those users have access to a
parent account record, they can also access its child opportunity, case, and contact records.
Database Architecture
Important: Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain
terms to avoid any effect on customer implementations.
Salesforce stores access grants in three types of tables.
Object Record Tables
Tables that store the records of a specific object, and indicate which user, group, or queue owns each record.
Object Sharing Tables
Tables that store the data that supports explicit and implicit grants. Most objects in your organization (to see them, from Setup, enter
Sharing Settings in the Quick Find box, then select Sharing Settings) get their own Object Sharing table, unless any of
the following conditions are also true:
•
The object is a detail in a master-detail relationship. In master-detail relationships, the Object Sharing table for the master object
controls access to the detail object.
•
Both organization-wide default settings (internal and external) are Public Read/Write.
•
The object is of a type that doesn’t support Object Sharing tables, such as Activities or Files. These objects have their own access
control mechanism.
Group Maintenance Tables
Tables that store the data supporting group membership and inherited access grants. For example, if the Object Sharing table grants
Bob explicit access to the Acme account record, Salesforce checks the Group Maintenance tables to see which users inherit record
access from Bob and grants users access to the Acme record. These grants are established in advance when you create or change
the group (or role, or territory) membership information.
While Object Sharing tables store access grants to individuals and groups, Group Maintenance tables store the list of users or groups
that belong to each group, indicating group membership. Both types of tables are used to determine a user’s access to data when they’re
searching, querying, or pulling up a report or list view.
When a user tries to retrieve one or more records, Salesforce generates a SQL statement that searches the Object Record table for records
matching the user’s search string. If the record exists, Salesforce appends SQL to the statement that joins the Object Records table with
the Object Sharing table, and the Object Sharing table with the Group Maintenance tables. Salesforce queries the joined tables for access
grants that give the querying user access to the record.
4
Database ArchitectureRecord-Level Access: Under the Hood