How to Prepare For and PASS Sharing and Visibility Designer Exam

In this post I would like to continue our journey with the Technical Architect (TA) Exam path. I’ve already covered the Data Architecture and Management Designer Exam in the previous post. To start with, I would like to concentrate on one, in my opinion, of the most challenging modules in the TA path. Ladies and gentlemen, let’s explore the Sharing and Visibility Designer Exam.
 

According to official exam guide:

A Salesforce Certified Sharing and Visibility Designer credential is created for architects, analysts, and administrators who want to demonstrate their knowledge, skills, and abilities to design secure, scalable security models on the Force.com platform. A Salesforce Certified Sharing and Visibility Designer should be able to communicate technical solutions to technical stakeholders and provide a project delivery framework that ensures quality and meets business requirements.

Exam spans really huge number of functionalities and aspects of Salesforce platform. Coming up with suitable sharing model is an essential step in designing sound solution that will provide secure application data access. During design phase it is important not only to assess current data access requirements but to also anticipate future ones. In this blog post I will try to cover all main certification areas and nitty-gritty of Salesforce sharing model.
 

Licenses

 
Before we dive into different sharing use cases and scenarios , it is worth realizing that different Salesforce licenses determine the baseline of features that the user can access. When designing the sharing model you have to know that some of the licenses do not utilize the sharing model at all (!) – like High Volume Customer Portal (HVPU) license. Familiarize yourself with the differences:

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 Force.com 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.

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.

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 Salesforce1 app access. The license doesn’t have access to CRM records (standard or custom objects) and Content functionality, and therefore, there is no sharing.

During my preparation for the exam I found a really nice diagram from Steven Herod that shows the relationships between the various license types:
 

To close the topic of HVPU license users I would like to mention Sharing Sets that are a way to make some of the records accessible to the users with that license. To play a little bit with that functionality you have to have the Community enabled in your org and then you can simply go to Customize -> Communities -> Communities Settings. You can then select which object type records you would like to share:
 

and then, based on the match of the selected lookup field in the the User’s object and the selected lookup on the target object system, it grants the access to the records that meet the critera:
 

Sharing Architecture

You have to be able to describe the features and capabilities available to restrict and extend the object, record, and field access.

• Permission Sets – a permission set is a collection of settings and permissions that give users access to various tools and functions. The settings and permissions in permission sets are also found in profiles, but permission sets extend users’ functional access without changing their profiles. 
• Profiles – profiles are typically defined by a user’s job function (for example, system administrator or sales representative). A profile can be assigned to many users, but a user can be assigned only to one profile. You can use permission sets to grant additional permissions and access settings to users.
• Organization-wide sharing settings — The first step in record-level security is to determine the organization-wide sharing settings for each object. Organization-wide sharing settings specify the default level of access users have to each others’ records.
• Role Hierarchy – represents a level of data access that a user or a group of users need. The role hierarchy ensures that users higher in the hierarchy always have access to the same data as people lower in their hierarchy, regardless of the organization-wide default settings.
• Sharing Rules – automatic exceptions to organization-wide sharing settings for particular sets of users, to give them access to records they don’t own or can’t normally see.
• Teams – a team is a group of users that work together on an account, sales opportunity, or case. Record owners can build a team for each record that they own. The record owner adds team members and specifies the access level each team member has to the record. Some team members can have read-only access, while others have read/write.
• Territory Hierarchy – The territory hierarchy is a single dimensional, additional hierarchy which can be structured by business units or any kind of segmentation in a hierarchical structure. When territory management is enabled you must manage both the role hierarchy and the territory hierarchy.

There are couple of questions regarding differences between profiles and permission sets, for example where can you specify login hours to the system (profiles only).
 

Profile

Permission Set

Every record must be owned by a single user or a queue. Concerning ownership there are a couple of questions that refer to the situation where single user possesses more than 10k records.

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

• The user record of the owner should not hold a role in the role hierarchy.
• 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.

Question:

Universal Containers has successfully implemented a large Service Cloud rollout for their national call center 3 months ago. One of their largest customer accounts, United Automotive, has over 15,000 open cases. Agents are now having trouble opening new cases for United Automotive. When they try to create a case, the following Error message appears for them:

UNABLE_TO_LOCK_ROW

They notice that this only occurs for the United Automotive account. If they try to save the case again it will usually work, but the problem seems to be happening more and more often.

Which option should the Architect recommend?

Choose one answer

A. Review all Account sharing rules to ensure that the Customer Service team has Read/Write access to the United Automotive Account.
B. Review the Account structure to split the United Automotive account into multiple branch accounts.
C. Review all Case Sharing Rules and consolidate where appropriate to reduce the total number of sharing rules.
D. Review the Customer Service Profile to ensure that they have Read/Write access to the appropriate Case and Account Fields.
 

Determining the Organization-Wide Defaults

 
To better grasp the concept of setting org-wide defaults I strongly recommend going through Trailhead module.

Once you find out answers to these questions you will know which sharing model suits your situation best:

Sharing Rules

There are two kinds of rules possible to define in Salesforce:

Ownership-based Sharing Rules – dependent on who owns the record in Salesforce

Example that is constantly repeated in different scenarios and questions – “a person in Service needs to be able to see some Sales data, but they live in different branches of the hierarchy”
 

Here I have to stop for a while and bring a Public Group concept. A public group is an administrator-defined grouping of users that can be used to simplify the creation of sharing rules. Each public group can be a combination of:

• individual users
• roles
• roles and subordinates
• other public groups

Criteria-based Sharing Rules – based on some combination of data elements on the record

The example – share Leads with certain Status with specially dedicated group.
 

Teams

 
There are 3 types of teams in Salesforce:

• Account Team
• Opportunity Team
• Case Team

The record owner adds team members and specifies the access level each team member has to the record. Some team members can have read-only access, while others have read/write.
 

Account Team fields. There would be also ‘Contact Access‘ field but as the organization-wide default for contacts is set to Controlled by Parent, it is not visible

Database Architecture

 
Salesforce describes its database architecture pretty nicely in PDF called Record-Level Access: Under the Hood.

Things that are worth learning:

Salesforce stores access grants in three types of tables:

• Object Record Tables – tables that store the records of a specific object, and indicate which user, group, or queue owns each record.
• Object Sharing Tables – tables that store the data that supports explicit and implicit grants. Each object has its own Object Sharing table unless the object is a detail in a master-detail relationship. In master-detail relationships, the Object Sharing table for the master object controls access to the detail object.

Let’s stick to such an example – Maria owns ACME account and shares it with Frank. Now Account Sharing Table has two records. One, obviously, is Maria, who is an owner and has full access to the ACME record. Frank was granted Read/Write access level to the mentioned account.
 

Now it’s easier to understand Manual Sharing (sometimes also called Apex Managed Sharing). If you want to create some logic that will share certain records in APEX code, you just have to create special records that will open access to the desired records. The aim is to create records of certain type, for example , all share objects for custom objects are named as MyCustomObject__Share, where MyCustomObject__c is the name of the related custom object.

When granting access you have to provide following information:

In code it would look something like that:

MyCustomObject__Share customShare = new MyCustomObject__Share();
customShare.UserOrGroupId = ‘someGroupId’;
customShare.RowCause = ‘important access’;
customShare.AccessLevel = ‘edit’;

• Group Maintenance Tables – tables that store the data supporting group membership and inherited access grants.

These tables store membership data for every Salesforce group. Let’s consider following role hierarchy:
 

Under the hood Salesforce generates such set of records:
 

See? Marc is a company’s CEO. Therefore he is an implicit member of every role in the system. He holds CEO Role but also Sales Exec Role, East Sales Rep, West Sales Rep, Services Exec and also Services Rep. Why is it built in that way? Every time you open the record the Salesforce has to determine if you have the access to it. It is much easier and faster to get that information from a special table than calculate everything in real-time. Bear in mind that in some large organizations with hundreds of hierarchy nodes, thousands of sharing rules, millions of data rows, and portals for customers and business partners processing such the amount of data would be impossible in reasonable time. That’s why, Salesforce calculates record access data only when configuration changes occur.
 

Reports

 
There are plenty of questions regarding reports and reports’ folders accessibility.

There are 3 access levels:

• Viewer Access – you can see the data in a report or dashboard, but you can’t make any changes, except by cloning it into a new report or dashboard. All users have at least Viewer access to report and dashboard folders that have been shared with them.
• Editor Access – when you are an Editor on a folder, you can view and modify the reports and dashboards it contains, and move them to and from any other folders you have Editor or Manager access to.
  
• Manager Access – with Manager access, you can do everything Viewers and Editors can do, plus control other users’ access to it, change its properties, or delete it.

Record Access for Enterprise Scale

 
In the end it is worth mentioning also some additional concepts that are refered in the exam.

• Granular Locking – when you make changes to roles and groups Salesforce locks the entire group membership table, which makes it impossible to process group changes in multiple threads to increase throughput on updates. Once you request enablement of this feature from Salesforce you can process some of updates simultaneously if there is no hierarchical or other relationship between the roles or groups involved in the updates.
• Deferred Sharing – imagine you have to rebuild the whole role hierarchy. If you have millions of records each change to the role hierarchy and group membership can take significant time as Salesforce has to recalculate the access to records. Instead , you would like to switch off sharing calculations, then do all the changes and after that switch on calculations again.