Territory hierarchy access – Understanding Salesforce sharing and security – Salesforce Certified Data Architect Study Guide

Territory hierarchy access

It is possible to create a hierarchy to represent your organization’s sales territories. This essentially facilitates automatic account assignment based on criteria to denote it belonging to a particular branch of the territory model. Chapter 12, Territory Management, covers territory management in further detail.

Programmatic sharing

Using what used to be known as Apex managed sharing, programmatic sharing allows the use of code to build sharing settings when data access requirements cannot be fulfilled using any of the means described in the preceding sections. Code-based sharing solutions can be quite fancy and sophisticated, but equally require careful management, and therefore it is important to understand how programmatic sharing works before embarking on a code-based sharing solution.

Each object in Salesforce has an associated share object. This has two naming conventions (one for standard objects and another for custom objects). For standard objects, the associated share object is named objectShare, such as AccountShare, CaseShare, and so on. For custom objects, the associated share objects are named using a format similar to object__Share. In the example of a custom object called MyObject__c, the associated share object is called MyObject__Share.

Objects that are on the detail side of a master-detail relationship don’t have an associated share object because access to the object on the Master side of the relationship grants implicit access to the object on the detail side. Custom objects that have a Public Read/Write OWD also do not have an associated share object.

When programmatically sharing a record using code, the associated share object requires an entry with a row cause to essentially store the reason the sharing has taken place. Sharing a record with a user through the Salesforce UI creates an entry in the associated share object with a row cause of manual share. Programmatic sharing can create entries with using the manual share row cause, but custom row cause values can be used. The values in a share object entry are as follows:

• ParentID: ID of the record being shared. This value cannot be changed once the row is created.

• RowCause: As explained in the previous paragraph, this is the reason why the record is being shared. This can bemanual sharing to simulate the Share button in the Salesforce UI being pressed, or a custom reason can be used. Custom sharing reasons need to be created in the Salesforce UI before they can be used. Objects have an Apex sharing reasons related list in the Management Settings of the object in Salesforce Setup.

• UserOrGroupId: The Salesforce ID of the user or group that the record is being shared with.

• objectAccessLevel: The level of access being granted as part of the share. The name of the property is the share object name of which the record is being shared followed by AccessLevel. For example, CaseShareAccessLevel. Values can be edit, or read, or edit or read-only access, respectively.

A Note on Records Shared Programmatically with Manual Share Row Causes

When records that are shared with row causes of manual share (both programmatically and through the UI) change owner, any manual share row cause records are removed from the associated share object. Custom row shares are persisted when a shared records owner changes.