Sharing and Visibility in Salesforce

In this post we will talk about Salesforce Sharing and Visibility. The Salesforce sharing model is an essential element in your organization’s ability to provide secure application data access. Therefore, it’s crucial to architect your sharing model correctly to meet your current and future data access requirements. In this post, we’ll review data accessibility components, sharing model use cases, and some tips for Salesforce Certified Sharing and Visibility Designer Exam.

Overview of Sharing Architecture

In Nov 2020, We did one session with Gemma on Salesforce Sharing and Visibility. In this post I want to highlight some great tips for Salesforce Certified Sharing and Visibility Designer Exam from that session. Sharing architecture is easily referred to in this handy pyramid that Salesforce provides in its Guide to Sharing Architecture

Who Sees What in Salesforce

You will be presented with many scenarios that assess your ability to understand why a user can or cannot see a specific field/record/object. Ensure that you understand the different tools at your disposal: record types, profiles, roles and role hierarchy, permission sets, manual sharing, programmatic sharing, and groups. Please check our old session on same topic.

Profiles and Permission Sets

Profiles and permission sets provide object-level security by determining what types of data users see and whether they can edit, create, or delete records. 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. Profiles and permission sets also control field-level security, which determines the fields within every object that users can access.

Record Ownership and Queues

Record owner have full Access to record and they can Read, Write, Delete & Transfer Records to other users.

• Record ownership is at the core of Salesforce’s record access capabilities
• It means that
  • Users have responsibility for the record and its maintenance
  • Users can collaborate in a structured way through teams and share tables
• Each record has 1 Owner – a user, queue or territory
• Only parent objects in a master-detail relationship may have Owners

Org-Wide Defaults (OWD)

OWD stands for Organization-Wide Default (OWD). Organization-Wide Default settings are baseline settings in Salesforce that specify which records can be accessed by which user and in which mode. These are applied per object (note that objects related via master-detail relationship will inherit the OWD from their parent). There are 3 types:

• Private: User will just have the ability to modify his/her own records. No access at all to other records.
• Public Read-Only: User will have read only access to all records. Their own and others too.
• Public Read/Write: User will have read and edit access to all records. Their own and others too.
• Public Read/Write/Transfer: Few objects (only Lead and case object) have this one extra option i.e. transfer. Transfer meaning that record owner is able to transfer his record to another user or queue).

Few objects will also have Controlled by Parent: If you chose this then record access is dependent upon settings of its parent object. This is only possible when master-detail relationship exists between the objects. This is available on standard objects such as contacts, being controlled by accounts

Role Hierarchy

Role hierarchy settings helps supervisor to see and edit records of their subordinates. We need to set users in roles hierarchy and grant access using hierarchy.

• Hierarchical structure
• Owner & those above in the hierarchy have full record access
• Align hierarchy to your org sharing requirements

Public Groups

Public Group represents a custom group of users defined by an administrator. Users can be added to a public group individually, or based on their assignment to a role (and its subordinates). Once an administrator has created a public group, other users in the organization can use it for security, content, and knowledge.

Sharing Grants

Take an example if USA Sales Team want to share opportunities with the INDIA Sales Teams and VP of Sales. There are a few ways you could share USA Sales Team opportunities with these individuals.

Sharing rules

Use sharing rules to extend sharing access to users in public groups, roles, or territories. Sharing rule allow administrators to automatically bypass organization-wide sharing settings. Sharing rules can open visibility to users in public groups, roles and territories, but are never used to restrict visibility

In this case we can create the criteria base / owner base sharing rule to share record with INDIA Sales Team and VP of Sales.

Manual sharing

You can use manual sharing to give specific other users access to certain types of records. Manual sharing option is not available in Salesforce lighting, so you need to switch to classic, in order to see this button and to share the records with another user.

Sometimes we encounters a scenario where individual users want to share their records with some other colleague (user). In that case manual sharing is best option.

Team sharing

An Account/ Opportunity team is a group of users that work together on an account/opportunity. Take an Example, We have a large, complex sales division. Org-wide defaults for account and opportunity are set to private. For strategic accounts, a team is established with users fulfilling various roles (sales engineer, sales rep, etc.). Instead of using manual record sharing to provide access to accounts, enable account teams. Not only will this solve the record sharing requirement, but will also provide a clear mechanism to document each user’s relationship to each account.

Apex sharing

There are situations where the business requirement is too complex and standard sharing rules provided by the Salesforce will not work. In that case we can use the Apex Sharing.

To access sharing programmatically, you must use the share object associated with the standard or custom object for which you want to share. For example, AccountShare is the sharing object for the Account object and for MyCustomObject it should be like MyCustomObject__Share. Here is sample code.

   public static boolean apexSharingDemo(Id recordId, Id userOrGroupId){
      MyCustomObject__Share myCustomObject  = new MyCustomObject__Share();
      myCustomObject.ParentId = recordId;
      myCustomObject.UserOrGroupId = userOrGroupId;
      myCustomObject.AccessLevel = 'Read';
      myCustomObject.RowCause = Schema.MyCustomObject__Share.RowCause.Manual;
      Database.SaveResult[] jobShareInsertResult = Database.insert(myCustomObject,false);
   }

Account Territories

Territory hierarchies are ways you can allocate an account to multiple territories, based on the structure of your sales strategy.

Further Leaning

• Other way to share check gemma blog.
• Check full recording