After Test Summary
Below is the Visibility & Sharing Certification Study Guide I compiled for myself. It contains the areas I needed a refresher on, mostly declarative sharing items. Hope it helps others too.
- Certification Trailmix
- Salesforce Sharing Architecture PDF
- Sharing Options in Communities
- Shield Platform Encryption
- Under the Hood – Record-level access guide from Salesforce
- Designing Record Access For Enterprise Scale
- Enterprise Territory Management – Sharing with Territory Management.
- Using Apex Managed Sharing to Create Custom Record Sharing Logic
- Declarative Sharing – 67%
- Performance – 8%
- Programmatic Sharing – 25%
Org-Wide Defaults control each object’s basic access for internal and external users. Then various other mechanisms allow one to grant additional access to share the records with others.
Other Sharing Mechanisms Summary
- Role Hierarchy
- Territory Hierarchy
- Sharing Rules
- Owner Based
- Criteria Based
- Manual Sharing
- Programmatic Sharing
These specify the baseline level of access that the most restricted user should have. They are used to lock down an object’s data and then role hierarchies, sharing rules, and manual sharing are used to open it up more as needed.
- Private – Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records.
- Public Read Only – All users can view and report on records, but only the owner, and users above that role in the hierarchy, can edit them.
- Public Read / Write – All users can view, edit, and report on all records.
- Controlled by Parent – A user can view, edit, or delete a record if she can perform that same action on the record it belongs to.
“Grant Access Using Hierarchies” – This setting controls whether or not roles above the record owner can see the record.
Standard Objects always have “Grant Access Using Hierarchies” checked.
Salesforce uses explicit grants when records are shared directly to users or groups.
- User or Queue becomes owner of a record.
- Sharing Rules shares record to a group, queue, role, or territory
- Assignment Rule shares record to user or queue
- Territory Assignment Rule shares the record to a territory.
- User manually shares.
- User becomes part of a team for an account, opportunity or case.
- Programmatic Share.
Group Membership Grants
Grants that occur when a user, personal or public group, queue, role, or territory is a member of a group that has explicit access to the record.
Grants that occur when a user, personal or public group, queue, role, or territory inherits access through a role or territory hierarchy, or is a member of a group that inherits access through a group hierarchy.
Grants that occur when non-configurable record-sharing behaviors build into Salesforce Sales, Service, and Portal applications grant access to certain parent and child records. For example, with this default logic, sometimes referred to as built-in sharing, users can view a parent account record if they have access to its child opportunity, case or contact record. If those users have access to a parent account record, they can also access its child opportunity, case, and contact records.
Role Hierarchy Access Groups
|Role||Users assigned to a specific role and one of its manager roles.||Used to give managers access to their subordinates’ records.|
|RoleAndSubordinates||Users assigned to a specific role and one of its manager roles and one of its subordinate roles.||Used when an organization defines a rule that shares a set of records with a particular role and its subordinates.|
|RoleAndInternalSubordinates||Users assigned to a specific role and one of its manager roles and one of its subordinate roles, excluding portal roles.||Used when an organization defines a rule that shares a set of records with a particular role and its subordinates, excluding portal roles.|
To create custom list views: Create Permission And “Create and Customize List Views” permissions are needed.
To create, edit, or delete public list views: Need “Manage Public List Views” user permission.
As an Admin or one with the “Manage Public List Views” permission, you have the option to hide the list view so only you can see this list view.
Choose the type of group or role from the drop-down list, select the group or role from the list, then click Add.
Enterprise, Unlimited, Performance, and Developer Edition users can give access to a public group or role, including all users below that role. To share the list view:
List views are visible to your community users with Customer Community Plus, Partner Community, Lightning Platform Starter, and Lightning Platform Plus licenses, if the Visible to all users setting is enabled for views of objects in community user profiles. To make list views visible only to your Salesforce users, select Visible to certain groups of users. Then share the view with the All Internal Users group or a selected set of internal groups and roles.
When implementing a community, create custom views that contain only relevant information for community users. Then make those views visible to community users by sharing them with the All Customer Portal Users group, or a set of community groups and roles.
Report Folder & Dashboard Folder Security
When you create a folder for a report or dashboard, you become its manager. Only you and others with administrative permissions can see it. If a folder does not have manager access, it’s public, and user with the “View Reports in Public Folders” permission can view it. Depending on their object access, these can also run the report.
A folder can be shared with up to 25 users, groups, or roles at one time. Up to 100 using the folder sharing REST API.
When a folder is shared, the following access grants are available:
- Viewer – View, Refresh & Run
- Editor – Viewer plus edit, move, save, and delete.
- Manager – Editor plus share and rename folder.
Note: If your primary dev org is older than Summer 13, you may have to enable “Enhanced Folder Sharing” to see these options like I did.
Three License Tiers: Customer Community, Customer Community Plus, and Partner Community.
Every user attached to an account. Person Accounts can only be tied to CC and CC+ users licenses. A single user can be associated to multiple communities.
Customer Community User License
Good for forum and knowledge base use cases. Scales to thousands or millions of users.
Customer Community Plus User License
Good for Self Service related things without buying things. Has full sharing model and access to reports and dashboards.
Partner Community User License
Highest level of access. Good for B2B scenarios and grants access to accounts, opportunities, and cases.
Sharing Sets To Grant High-Volume Community Users Access to Records
“Customize Application” user permission needed to manage sharing sets.
A sharing set grants high-volume users access to any record associated with an account or contact that matches the user’s contact or account. You can also grant access to records via access mapping in a sharing set, which supports indirect lookups from the user and target record to the account or contact. For example, grant users access to all cases related to an account that’s identified on the users’ contact records. Source
Determine how access is granted using an access mapping in the sharing set, which supports lookups from the user and target record to the account or contact. You can determine the objects to use in the access mapping, and they must both either point to an account or contact. Source
Sharing Sets apply to users across communities.
Sharing Groups To Share Records Owned By High-Volume Community Users
High-volume users are limited-access users intended for organizations with many thousands to millions of external users. Unlike other external users, high-volume users don’t have roles, which eliminates performance issues associated with role hierarchy calculations. Because high-volume community users are not in the role hierarchy while Salesforce users are, a share group allows you to specify the Salesforce other external users who can access records owned by high-volume community users.
Salesforce’s original territory management feature lets you grant users access to accounts based on criteria such as postal code, industry, revenue, or a custom field relevant to your business. Enterprise Territory Management builds upon the original feature by introducing territory types, territory models, and territory model states. Source
Enterprise Territory Management
Consists of Territory Type Priority and Territory Model. An org can have up to 4 models but only 1 active one at a time. The Territory Hierarchy shows a model’s territory structure and serves as the main interaction point. Source
Assignment Rules automatically assign an account to a territory when an account is created or edited. This is Enterprise only. An account can have one or more territories assigned to it. Territories can also be assigned to opportunities. When you assign a territory to an opportunity, that opportunity is shared with all Salesforce users assigned to that territory’s parent in the territory model’s hierarchy.
Main Differences Between Territory Management 1.0 and Enterprise Territory Management (2.0)
|Features||Territory Management 1.0||Enterprise Territory Management 2.0|
|Run Territories on Territory Tree/List View Page||X|
|Preview Territory||X(partial, not persisted)||X|
|Inherited Territory Rules||X||X|
|Enable/Disable Territory Management||X||X|
|Assignment of Territory on Opportunities||X||X (Spring ’15)|
|Integration with Customizable Forecasting||X|
|Integration with Collaborative Forecasting||X (Forecasts based on Role Hierarchy, not Territory Hierarchy)|
|Manual Assignment of Account to Territory||X||X|
|Separation of Rule Execution vs Deployment||X|
|Territory Hierarchy Deep Clone||X|
|Rule Sharing among multiple Territories||X|
|My Territories Scope in Account List Views||X||X|
|My Territories Scope in Account Reports||X||X (Spring ’15)|
|Metadata API Support||X|
|User Role in Territory||X|
|Trigger on User to Territory Association Object||X|
|Share a report/dashboard folder with a territory||X|
|Create a public group with territory||X|
CRM Content Info
Content shared through Libraries. Each Salesforce CRM Content user license needs to have certain permissions. Each user has one personal library where he or she can store private or in-progress content. Customer Portal and Partner Portal users can have view-only access without a Salesforce CRM Content user license.
CRM Content User Permissions
- Manage Salesforce CRM Content – Create, Edit, and Delete libraries and edit library membership. This is inclusive of the other four CRM Content User permissions below.
- Create Libraries – Create CRM Content Libraries.
- Manage Content Permissions – Can Create, Edit, and Delete library permissions
- Manage Content Properties – Can create, edit, and delete custom fields.
- Manage Record Types and Layouts For Files – Can create, edit, and delte record types and page layouts in CRM Content.
Default Library Permissions: Viewer, Author, & Administrator.
All Page Layouts have 3 default fields: Description, Tags, and Title.
Can add Google docs to CRM Content.
An external object is a table in an external system that maps to an External Object in Salesforce.
Permissions Needed: Customize Application
An external object can be granted access through a profile or permission set.
It is possible to manually share a record to a user or a group using Apex or the SOAP API. If the owner of the record changes, the sharing is automatically deleted. The following example class contains a method that shares the job specified by the job ID with the specified user or group ID with read access. It also includes a test method that validates this method. Before you save this example class, create a custom object called Job. Source
Without an Apex Managed Sharing Reason, a manual sharing rule is deleted when a record’s owner changes.
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 Force.com 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.
DISCLAIMER: Apex sharing reasons and Apex managed sharing recalculation are only available for custom objects.