Sharing rules – Understanding Salesforce sharing and security – Salesforce Certified Data Architect Study Guide

Sharing rules

Sharing rules exist to provide exceptions to the OWD and role hierarchy, opening up users record access based on conditions. Sharing rules fall into two categories:

  • Owner-based sharing rules: These allow records to be shared with other users based on the owner of the record, such as peers within the same role.
  • Criteria-based sharing rules: These allow records to be shared with other users based on the criteria of the record (a value of a field, for example). Record ownership is not a consideration, as that scenario is covered by owner-based sharing rules.

Manual sharing

In bespoke sharing scenarios not covered by the mechanisms we’ve covered already, manual sharing exists to provide a facility to manually share a record, granting read and edit permissions, with users who don’t

have access to the record. Manual sharing, as the name implies, is a user-driven process that involves clicks in the Salesforce user interface to grant record access to other users. It is possible to create manual

shares programmatically (for more information, see the dedicated subsection on Programmatic sharing).

Sharing a record with another user creates a share record in the Salesforce database. Programmatic solutions will need to manage record shares for share reasons other than manual share. Programmatic shares with a manual share row cause can be maintained using the Share button on the record, much

like the out-of-the-box share button functionality.

When Manual Shares Cease to Work

If a record owner of a shared record changes, then the manual share is removed. If the sharing doesn’t open up access beyond what is set in the OWD for that object, the share isn’t created in the first place. Both of these statements are also true in programmatic scenarios.

Team access

Accounts, opportunities, and cases have a teams record-sharing concept, whereby groups of users can work collaboratively on accounts, opportunities, or cases. The record owner, someone higher in the role hierarchy (who therefore inherits the same level of record access), or administrators can add people to a team to work collaboratively on a record or modify the access level (say, from read-only

to read/write).

Teams are generally used to give specific users in Salesforce an elevated level of access to a record so

that they can work collaboratively on an account, opportunity, or case. For example, if a user already

has write access to a particular account record, adding them as read/write in the account team for that record has no effect.

Creating a team against an account, opportunity, or case record creates a team record and an associated share record in the Salesforce database. Programmatic solutions will have to maintain both of these

records. See the dedicated subsection for more information on programmatic sharing.

What About Multiple Teams Accessing One Record?

If multiple teams are required to access a particular record, then territory management or programmatic sharing may be more suitable. There is only one team per account, opportunity, or case, and therefore the concept of multiple teams against a single record is not supported.