A GUIDE TO SHARING ARCHITECTURE -NOTES

• Record ownership and full access are synonymous and interchangeable and provide the user with the highest level of access to a record.

Licenses 

1. Full Sharing Model Usage Users/Licenses Most Standard Salesforce license types take full advantage of the sharing model components. The license might not make a module accessible, or even some objects accessible. For example, the Free edition can’t access any CRM objects. However, the sharing entities, and functionality, still exists and is ready when and if the module ever does become active.

2. High Volume Customer Portal License High Volume Customer Portal (HVPU) license users (including Community and Service Cloud license users) do not utilize the sharing model. HVPU licenses have their own sharing model that works by foreign key match between the portal user (holding the license) and the data on Account and Contact lookups. HVPU license is only used for the Customer Portal and not the Partner Portal.

3. Chatter Free License The Chatter Free license doesn’t follow the standard sharing model. Chatter Free is a collaboration-only license with the following features: Chatter, Profile, People, Groups, Files, Chatter Desktop, and limited Salesforce app access. The license doesn’t have access to CRM records (standard or custom objects) and Content functionality, and therefore, there is no sharing.

• For each object, the “View All” and “Modify All” permissions ignore sharing rules and settings, allowing administrators to quickly grant access to records associated with a given object across the organization. These permissions are often preferable alternatives to the “View All Data” and “Modify All Data” administrative permissions.

• Every record must be owned by a single user or a queue.

• Users higher in a hierarchy (role or territory) inherit the same data access as their subordinates for standard objects. Managers gain as much access as their subordinates. If the subordinate has read-only access, so will the manager. This access applies to records owned by users, as well as records shared with them.

If a single user owns more than 10,000 records, as a best practice: • 

1. The user record of the owner should not hold a role in the role hierarchy.

2. If the owner’s user record must hold a role, the role should be at the top of the hierarchy in its own branch of the role hierarchy.

• Organization-wide defaults are the only way to restrict user access to a record.

• For custom objects only, use the Grant Access Using Hierarchies setting, which if unchecked (default is checked), prevents managers from inheriting access.

• Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.

• An organization is allowed 500 roles; however, this number can be increased by Salesforce.

• As a best practice, keep the number of non-portal roles to 25,000 and the number of portal roles to 100,000.

• As a best practice, keep the role hierarchy to no more than 10 levels of branches in the hierarchy

• Overlays are always the tricky part of the hierarchy. If they’re in their own branch, they’ll require either sharing rules, teams, or territory management to gain needed access. If they are folded into the hierarchy, there might be reporting implications.

                                                            SHARING

Public Groups:- Public groups can consist of: 

1. Users

2. Customer Portal Users

3. Partner Users

4. Roles

5. Roles and Internal Subordinates

6. Roles, Internal and Portal Subordinates

7. Portal Roles

8. Portal Roles and Subordinates

9. Territories

10. Territories and Subordinates

11. Other public groups (nesting)

• Groups can be nested (Group A nested into Group B), however don’t nest more than five levels.

• Nesting has an impact on group maintenance and performance due to group membership calculation.

• As a best practice, keep the total number of public groups for an organization to 100,000.

• Group membership alone doesn’t provide data access.

Ownership-based Sharing Rules:-

• Ownership-based sharing rules allow for exceptions to organization-wide default settings and the role hierarchy that give additional users access to records they don’t own. 

• Ownership-based sharing rules are based on the record owner only. 

• Contact ownership-based sharing rules don’t apply to private contacts. 

• As a best practice, keep the number of ownership-based sharing rules per object to 1,000

Criteria-based Sharing Rules:- 

• Criteria-based sharing rules provide access to records based on the record’s field values (criteria). If the criteria are met (one or many field values), then a share record is created for the rule. 

• Record ownership is not a consideration. 

• As a best practice, keep the number of criteria-sharing rules per object to 50; however, this can be increased by Salesforce