Sharing Model
The sharing model defines how record-level privileges are granted to users who do not own the record. Configuring the sharing model is a two-part process. Organization-wide defaults are used to establish the most restrictive level of access for each object. Sharing reasons override the defaults to grant access to individual records.
Organization-Wide Defaults
Every object that allows record ownership has an organization-wide default setting dictating how records are shared between the owner and other users. Custom objects have several default settings:
Private—Records belong to the owner and only the owner. With the exception of the data administration-level privileges View All and Modify All, records are accessible only to their owners.
Public Read-Only—Any user can view records in this object but cannot edit or delete them. Only the owner and users with administrative privileges have rights to edit and delete.
Public Read/Write—Any user can view, edit, and delete records in this object. All newly created custom objects default to this setting.
Controlled by Parent—This option is available only to child objects in Lookup relationships. It delegates record-sharing decisions to the parent record. The child records behave as if they lack an owner. Objects with this default setting have the same record-sharing behavior as children in a Master-Detail relationship.
When setting organization-wide defaults, begin with the user to receive the minimum access to data. Set the organization-wide default settings with this user in mind. All users then have at least this level of access to records. To configure organization-wide defaults, click Setup. In the Administration Setup area, click Security Controls, Sharing Settings. Figure 3.6 shows the screen with organization-wide defaults.
The rightmost column of check boxes called Grant Access Using Hierarchies determines whether the role hierarchy is used on this object to propagate permissions upward to superior roles. By default, this behavior is enabled. Disabling it causes roles to function like public groups. Record permissions are shared only between a pair of roles, never aggregated up the role hierarchy.
Sharing Reasons
Sharing reasons override the organization-wide defaults to allow individual records to be shared between groups of users. The groups can be roles or public groups. The behavior of the sharing reason depends on the groups involved and the type of sharing reason.
Sharing between roles results in asymmetric privileges. Users in subordinate roles do not receive any privileges of their superiors, but superiors receive all the privileges of their subordinates. Sharing with public groups is symmetric, granting equal rights to both parties. In other words, a user has access to all records that are accessible to its descendants in the role hierarchy.
Note
Objects with the most permissive organization-wide default (public read/write) cannot use sharing reasons.
Objects with the most permissive organization-wide default (public read/write) cannot use sharing reasons. The four types of sharing reasons are as follows:
1. Manual—The owner of a record can elect to manually share it with another user or group of users. The owner specifies the level of access (Read Only or Read/Write) to be granted. To configure manual sharing, click the Sharing button on a detail record in the Force.com native user interface. Figure 3.7 shows the user interface for sharing a record named GenePoint in the Project object.
2. Sharing rules—Sharing rules allow records to be shared automatically by Force.com based on group membership or arbitrary criteria. In Figure 3.8, a sharing rule is being created for the Project object. It specifies that members of the West business unit can automatically read and write all Project records owned by their colleagues in the same business unit. In Figure 3.9, a criteria-based sharing rule is being defined to provide users in the Executive role with Read and Write access to billable projects.
3. Procedural—Records can be shared programmatically using Apex code. This allows a developer to define the conditions that govern the sharing of a record. This is discussed in Chapter 5, “Advanced Business Logic.”
4. Delegated administration—Profiles contain two special systems permissions called View All Data and Modify All Data. If these are granted, they exempt users in that profile from all sharing rules, giving them access to all records regardless of owner. This privilege is intended for data import, export, and cleansing programs that need to run unencumbered by sharing rules.