Visibility & Sharing Certification Study Guide

After Test Summary

I passed! This was a little tricky but not so bad. Definitely make sure you learn Territory Managment and Enterprise Territory Management, the differences between the two, and how they affect forecasting and record sharing. There were many questions on that. There were also security questions relating to SOQL injection, Javascript detection that I didn’t expect but thankfully I knew those topics already. Definitely ensure you know the platform security options cold because OWDs, profiles, permission sets, Account, Case, & Opportunity Teams, were heavily questioned.

Overview

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.

Study Resources

• eBook
• 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

Exam Outline

• Declarative Sharing – 67%
• Performance – 8%
• Programmatic Sharing – 25%

Record Sharing

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
• Teams
• Manual Sharing
• Programmatic Sharing

Org-Wide Defaults

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.

Access Grants

Source

Explicit Grants

Salesforce uses explicit grants when records are shared directly to users or groups.

Examples

• 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.

Inherited Grants

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.

Implicit Grants

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

Group	Consists Of	Purpose
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.

ListViews

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.

Source

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.

Source

Community Info

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.

Source

Territory Management

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
Multiple Territories/Hierarchy		X
Run Territories on Territory Tree/List View Page		X
Preview Territory	X(partial, not persisted)	X
Inherited Territory Rules	X	X
Territory Type/Priority		X
Territory Models		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
Reports/Dashboards	X	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)
Audit Trail		X
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

Source

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.

Source

External Objects

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.

Source

Programmatic Sharing

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.

Other Sources

• David Liu’s Ultimate Certification Guide – A Must Read!
• Swayam Chouksey Medium Post
• Exam Tips From Gemma Emmett at Always a Blezard