SHARING AND VISIBILITY DESIGNER : Exam preparation guide and tips

I had started planning for Salesforce Application Architect journey in Nov, 2017. As in order to achieve this, I need to passed below mention 2 exam as other required exams I had already cleared.

• Certified Sharing and Visibility Designer
• Certified Data Architecture and Management Designer

As Sharing and security is my favorite, so I start preparing for "Certified Sharing and Visibility Designer" exam. It took almost 1 month for preparation and finally I cleared first architect exam on 30 Dec, 2017.

Through this blog, I am going share my preparation experience and tips for everyone who all are planning for this.

• For self study, please refer Resource Guide for Sharing and Security, which contains all the study material links for different topics. If you complete this, then you are ready for this exam. 
• Please do practice on all topics related to declarative sharing and programmatic sharing.

This exam contains three sections:

1. Declarative Sharing (68%)
2. Programmatic Sharing(25%)
3. Performance(8%)

Tips on different sections:

Declarative Sharing

• Candidate must have complete understanding of different record sharing in built functionality like OWD, Role Hierarchy, Sharing Rules, Manual Sharing, Teams, Territories etc.
• Custom permissions, Profiles and permission sets.
• As I was not able to do practice on Territories, I just went through Salesforce help section for territories. Important topics are difference between Territory management(1.0) and Enterprise Territory Management (2.0) and their capabilities.
• Must do practice on Account Teams and Opportunities. Different scenarios like who all can add team members, who can change record owner, what level of access can be given to user considering object OWD setting etc.
• Permission required for creating list views and with whom all list view can be shared.
• Custom settings, named Credentials and Custom metadata.
• Ownership Skew, Lookup Skew and Account Skew and their impact on performance.
• Always remember that manual sharing of record or manual sharing created through apex get deleted when record owner changes.
• Differences between shield and classic encryption.
• Record Access Grants(Implicit grant, Group membership grant, Inherited grant and explicit grant).
• Reports and dashboard folder access and permission required to manage this. Also cover different types on file and folder access permissions.
• Always remember that External default sharing level of object should be equal to or less restrictive than internal default sharing level.
• Public groups (who all can be added and how access can be restricted to higher role using public groups).

Programmatic Sharing

• How to force object permission and FLS in apex and VF page (using schema describe methods).
• How to use apex manage sharing for standard objects and custom objects

Performance

• Granular locking: Usually group membership get locked if any configuration happens. This will make impossible to perform group membership changes during this lock period.  If Granular locking feature is enabled then system will lock portion of records instead of locking entire Group maintenance table. This allow multiple update simultaneously if there is no hierarchical or other relationship between the roles and groups involved in the update.

• Parallel Sharing rule calculation:  If Salesforce perform any activity (maintenance or upgrade)  then all sharing recalculation jobs get killed. In order to avoid this, consider enabling parallel Sharing Rule calculation. This will split the job in multiple threads which will run asynchronously. If Salesforce perform any activity, these jobs will not be killed and resume after salesforce activity.

• Deferred Sharing Calculation : Best fit if you can buy out maintenance window from live user. Once you enable this, system will not perform any sharing calculation and you can perform major configuration changes like role changes, public group reassignment etc.

• Avoid Account data skew, lookup skew and ownership data skew.

• Avoid creating more nested public groups

You ran refer below mentioned my blogs links which explain things in summarized way:

• Access Grants
• Consideration for large scale implementation
• Custom Permission
• Decleration Sharing v/s Programmatic Sharing

Hope this will help!!

Custom Permissions : Way to control user access to different functionality in Salesforce

Problem Statement

There is a very common scenario in which admin has to configure different validation rules, workflow rules which fires based on User Id or Profile Id.

Consider below mentioned scenarios:

• Position (Custom Object) records can be closed by user belonging to specific profile.
• You have created a VF page where you display specific section to users based on profile. 

In both scenarios, you have to check for profile Id in validation rule as well as in VF (to rendered specific section).

Now after some time if you have to enable the above mentioned functionality to new profile or to specific user then, you have to modify the validation rule as well as your VF page code.

Solution

You can use custom permission for these kind of scenarios.

Custom permission is just a record which can be referenced in validation rule, workflow rules, VF, Apex etc. You can assign custom permission to profile or permission set (similar way in which we assign VF page and Apex class).

Now you can check custom permission in validation rules and VF by using global $Permission variable.

Steps to use custom permission and use as per above scenario:

• Create custom permission (Navigate to Set Up--> Develop--> Custom Permissions).
• Create new custom permission.

• Add custom permission to profile or permission set(navigate to Enable custom permission section).

• Modify the validation rule to and VF to refer custom permission instead of profile id.

So custom permission help us to control different functionality in salesforce to different users. If you have to enable functionality for single user then add custom permission to permission set and then add that permission set to user.

Alternate Approach

All admins/developers were using custom setting to control functionality for different users but after launch of custom permission, jobs of developer or admin will be easy.

Custom Permission in Apex

You can use below static method to find out list of user who have permission for custom permission:

public static List<User> findUsersWithCustomPermission(String customPermissionname)

{

    List<user> userList = new List<User>();

Set<Id> permissionSetIds = new Set<Id>();

    for (SetupEntityAccess access : [ SELECT ParentId FROM SetupEntityAccess 

WHERE SetupEntityId IN ( SELECT Id FROM CustomPermission 

            WHERE DeveloperName = :name)]) {

        permissionSetIds.add(access.ParentId);

    }

if(permissionSetIds.size()>0){

userList = [SELECT Username FROM User 

WHERE Id IN (SELECT AssigneeId FROM PermissionSetAssignment

WHERE PermissionSetId IN :permissionSetIds)];

}

    return userList;

}

Hope this will help!!!

Access Grants : Record Access Calculation in Salesforce

Salesforce always check record accessibility whenever user view record in order to maintain data visibility as per sharing settings specified in org. Record access can be granted based on role hierarchy, sharing rules, in-built sharing etc.

Imagine a large scale implementation which involve large number of roles, sharing rules and customized apex managed sharing. In order to determine user access for record by considering  this scenario will take lot of time and will result in performance issue.

In order to avoid this kind of performance issues, Salesforce doesn't calculate record access in real time but it calculate record access whenever any configuration change occurs and store that information. This helps in calculating the record access in real time instead of traversing all hierarchies, applying all sharing rules or analyzing other available record sharing mechanism.

Access Grants

Salesforce uses Access Grants in order to identify how much access user have to object records. This comes into picture only when OWD for object is either PRIVATE or PUBLIC READ ONLY.
Access Grant also specify the sharing tool (like sharing rule, teams,roles etc) responsible for providing record access to user.

There are four types of access grants used by Salesforce:

• Explicit Grants

Salesforce uses explicit grants when records are shared directly to user or groups. Below are few scenarios which are considered under this:

1.  Teams : When user is part of account, sales or case team.
2. When user or queue becomes record owner. All users under that queue get access to record.
3. When record is shared by using sharing rule, apex manage sharing and manual sharing.
4. When record is shared with user or queue based on assignment rule or territory rules share record with territory. All users under that territory get access to record.

Note: If you are using Enterprise Territory management, user can not share record manually to territory and while using sharing rules or apex managed sharing, record can not be shared with territory groups.

• Implicit Grants

This is called as built-in sharing in salesforce. These are predefined record sharing behavior for  Sales, Service and portal applications. For example:

1. User can view parent account record if they have access to child opportunity, case or contact record.
2. If user has access to parent account, then they can access child opportunities, cases and contact records.

• Group Membership Grants

This grant comes into picture when user, personal or public group, queue, role or territory is a member of group that has explicit access to record. So it means all user users or group which are part of public group with which any record is shared, the all group members and members present in sub-group  will get access to records.

• Inherited Grants

This comes into picture when user get access to records because of role hierarchy, territory hierarchy or inherit access through group hierarchy.

Sharing database Architecture

Salesforce store access grants in three types of tables:

• Object Record Tables

This table indicate which user, group or queue own each record.

• Object Sharing Tables

This table store information like which record is shared with which user or group either by apex manage sharing rule or declarative sharing when object OWD is not PUBLIC READ/WRITE.

This table store data that supports explicit and implicit grants.

• Group Maintenance Tables

This table store data that supports group membership grants and inherited grants. 

Declarative Sharing Vs Apex Managed Sharing

Force.com platform provides declarative sharing option which are easy to configure and meets basic data sharing requirements.

Different declarative sharing options

• Record Ownership

Record owner will have read, edit, delete, share and transfer access.

• Teams

Account teams, sales team and case team allow group of users to have access to different account, opportunities and case records.

• Role hierarchy

This allow users in higher role to have same level of access to data which users have in lower hierarchy.

• Sharing rules

You can create owner based or criteria based sharing rules in system which will open up the record access to users. Records can be shared to public group, roles,roles and internal subordinates, roles internal and portal subordinates etc.

Sharing rules also allow to share data with external users. The default external access level must be more restrictive or equal to default internal access level.

For example, if external sharing default is set to Public Read-Only for custom object, then valid internal default settings will be Private and Public Read Only.

• Manual Sharing

Manual Sharing is also known as User Managed Sharing. This option allow user to share record manually with another user or public group, portal roles, portal users, roles, roles and internal subordinates, roles internal and portal subordinates etc.

Remember if record owner share record manually with another user and later on record owner changes, then manual sharing record will be deleted.

Apex Managed Sharing

This allows developers to share records by using apex code. This is also known as "Programmatic Sharing". Object share records can be created for standard and custom object but custom sharing reason can be defined for custom object only.

For example, if we have to share a record with a user specified in lookup field, then you can use trigger to create record in share table to provide access. 

Valid access level for records are Edit/ Read.

If OWD for object is either Public Read only or Private, then share table will exist for that object. You can create record in that share table to provide access to any user. Below are 4 fields you need to specify in order to create record in share table:

• ParentId : 15 digit or 18 digit id of record which you want to share.
• UserOrGreoupId : User id or group Id
• Access Level : Edit or Read. This field must be set to an access level that is higher than the organization’s default access level for the parent object.
• RowCause : You can specify the reason for sharing record. First define sharing reason for custom object. For standard object, you can specify Manual.

 You can not update ParentId field.

You can share record with same user or group by using different sharing reasons.

Consideration while using Apex Managed Sharing

• If record owner changes, then sharing created through apex managed sharing (if row cause is not manual and uses custom sharing reasons) are maintained but if user share record manually, then record sharing will be lost if owner changes.
• User with "modify All Data" can only add, edit or delete records in share table.

Important Things to Consider for Record Access while Designing Large Scale Applications

As we already know through Organization wide default, record access to different users in system can be controlled. Apart from OWD, user can get record access through role, being a part of public group with which record is shared, territories etc. In order to control access of records, Salesforce maintain record sharing data and recalculate the sharing when any changes happen to role, territory, public group etc. For end user, changing user's role is simple operation but at the back end, Salesforce has to perform all record sharing recalculation based on user's new role.

Lets discuss all this in details. First we will start with Database Architecture. Salesforce maintains 3 types of tables as mentioned below:

• Object Record Table

These are the tables which stores records of specific object and indicate which user or queue owns each record.

• Object Sharing Table

If OWD of any object is public read only or private, the Salesforce create share table for that object.This table store information about record access for all users which is shared by explicit grant (shared with user or group) or implicit grant (built in sharing like access to child opportunity, cases if you have access to account record).

• Group Maintenance Tables

This table stores list of users or groups that belong to each group indicating group membership. Suppose a record is shared with group, then Salesforce check group maintenance table to identify which all users inherit access to that record (either through role hierarchy, group membership or through territories).

So when Salesforce has to find out that if user has access to record, then it perform join between three tables to identify record access for user. If user is owner of record, then it will display that record. If not it will check object sharing table and group maintenance table to find users access to record.

Salesforce Role hierarchy, public groups and territories are closely connected with sharing rules and security features. Suppose an user owns more than 10,000 records and now admin just changed this role. Now salesforce need to remove access to all these records for all user which are having higher role than user's previous role and need to provide access to all user's in higher role than new user's new role. So Salesforce has to recalculate the record access and sometimes it may take more time.

In order to handle these scenarios, Salesforce provide few tools which can be used to avoid these issues caused by user realignment either through roles, territory or public groups:

• Parallel Sharing Rule Calculation

Whenever admin changes user's role or change group membership or create, edit or delete sharing rules, then recalculation for record access happens synchronously. So when any of these changes affects access right to large number of records, the recalculation job take longer time. If any Salesforce perform any activity at this time like patch release or upgrade, then recalculation jobs get killed. In this scenrio, consider parallel Sharing Rule calculation. This will split the job in multiple threads which will run asynchronously and if Salesforce perform any activity, these jobs will resume after salesforce activity.

Contact Salesforce in order to enable this feature.

• Deferred Sharing Maintenance

Suppose you have rebuild the role hierarchy and group membership, the sharing recalculation may take significant time. In this kind of scenarios, you can enable deferred sharing which will allow admins to switch off of sharing recalculation and perform all role and group membership changes and then switch on sharing calculation. After switching on sharing calculation, admin has to start recalculation of all sharing rules for accurate user access rights.

Remenber deferred sharing doesnot stop sharing recalculation due to implicit sharing.

Contact Salesforce in order to enable this feature.

• Granular locking

Whenever any change is performed to roles or group, Salesforce locks entire Group membership table to protect data integrity. This will make impossible to perform group membership changes. Consider a scenario in which your users are facing frequent record locking error and restrict their ability to manage manual and automatic update at same time or degrade the group maintenance updates, then enable Granular Locking feature.

If Granular locking feature is enabled then system will lock portion of records instead of locking entire Group maintenance table. This allow multiple update simultaneously if there is no hierarchical or other relationship between the roles and groups involved in the update.

You need to contact Salesforce to enable Granular locking feature.

More Blogs>>: 

DYNAMIC APEX IN SALESFORCE
SOQL INJECTION IN SOQL
CUSTOM METADATA AND CUSTOM SETTINGS IMPLEMENTATION TRICKS
SMART TABLE USING ANGULARJS IN VISUALFORCE PAGE
REST API TUTORIAL FOR SALESFORCE
VISUALFORCE COMPONENT FOR RECORD STATUS BAR
DYNAMICALLY CREATING AND DESTROYING LIGHTNING COMPONENTS    
RAISING AND HANDLING CUSTOM EVENTS IN sALESFORCE lIGHTNING    
WHY TO USE DESIGN RESOURCE AND HOW TO ADD DYNAMIC OPTION TO DATASOURCE    
PASSING INNER WRAPPER CLASS TO LIGHTNING COMPONENT    
LIGHTNING COMPONENT FOR RECORDTYPE SELECTION FOR ANY SOBJECT