sharingmodel1 This post is a direct continuation from the last post, detailing sharing on the Salesforce platform. In this second part series, coding examples will be provided to cement the whole programmatic sharing in Salesforce.

Sharing Naming Convention

To access sharing programmatically, you must use the share object associated with the standard or custom object for which you want to share. For example, AccountShare is the sharing object for the Account object, ContactShare is the sharing object for the Contact object. Also, all custom object sharing objects are named as follows, where MyCustomObject is the name of the custom object: MyCustomObject__Share. >Objects on the detail side of a master-detail relationship do not have an associated sharing object. The detail record’s access is determined by the master’s sharing object and the relationship’s sharing setting.

A share object includes records supporting all three types of sharing: - Managed sharing - User managed sharing - Apex managed sharing

Sharing granted to users implicitly through organization-wide defaults, the role hierarchy, and permissions such as the “View All” and “Modify All” permissions for the given object, “View All Data,” and “Modify All Data” are not tracked with this object. Create a custom Object in Salesforce called Essence.

User managed sharing using apex

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Essence__Share  share = new Essence__Share();
// can be Edit or Read
share.AccessLevel = 'Edit';

// a valid user or public group id
share.UserorGroupId = 'a user id or public group id';

//RowCause can be ommited, manual by default
share.RoWCause = Schema.Essence__Share.RowCause.Manual;

// ID of the object being shared
share.ParentID = 'object id';
//save share object
insert share;

Creating apex managed sharing

Apex managed sharing enables developers to programmatically manipulate sharing to support their application’s behavior through Apex or the SOAP API. This type of sharing is similar to managed sharing. Only users with “Modify All Data” permission can add or change Apex managed sharing on a record. Apex managed sharing is maintained across record owner changes.

Apex managed sharing must use an Apex sharing reason. Apex sharing reasons are a way for developers to track why they shared a record with a user or group of users. Using multiple Apex sharing reasons simplifies the coding required to make updates and deletions of sharing records. They also enable developers to share with the same user or group multiple times using different reasons.

Apex sharing reasons are defined on an object’s detail page. Each Apex sharing reason has a label and a name: - The label displays in the Reason column when viewing the sharing for a record in the user interface. This label allows users and administrators to understand the source of the sharing. The label is also enabled for translation through the Translation Workbench. - The name is used when referencing the reason in the API and Apex.

All Apex sharing reason names have the following format: >MyReasonName__c

Apex sharing reasons can be referenced programmatically, for example, a sharing reason called LockDown: >Schema.Essence_Share.RowCause.LockDown__c

When working with Apex sharing reasons, note the following: 1. Only users with the “Modify All Data” permission can add, edit, or delete sharing that uses an Apex sharing reason. 2. Deleting an Apex sharing reason will delete all sharing on the object that uses the reason. 3. You can create up to 10 Apex sharing reasons per custom object. 4. You can create Apex sharing reasons using the Metadata API.

To create an Apex sharing reason: 1. Switch to classic mode -> Object -> Object Name, click New in the Apex Sharing Reasons related list. 2. Enter a label for the Apex sharing reason. The label displays in the Reason column when viewing the sharing for a record in the user interface. The label is also enabled for translation through the Translation Workbench. 3. Enter a name for the Apex sharing reason. The name is used when referencing the reason in the API and Apex. This name can contain only underscores and alphanumeric characters and must be unique in your org. It must begin with a letter, not include spaces, not end with an underscore, and not contain two consecutive underscores.