Salesforce Sharing: How To

There are many different elements to Salesforce sharing and data visibility, which can be daunting at first. However, once you understand all the elements, it becomes very clear the reasoning and value behind all the various functions. It also helps understand how flexible and granular data access in Salesforce can be.

I first want to explain the different methods of data sharing and security in Salesforce, and then run through some common examples of sharing requirements and how best to address them. 

Salesforce Sharing Functionality

Organisation Wide Defaults (OWD)
Organisation wide defaults are the base level sharing assigned to objects within an organisation. This is broken down into 3 types:

Public Read/Write
This is the default level of sharing assigned to objects by default. This allows for all records to be seen and edited by all users, assuming they have read and edit access to the object at a profile or permission set level. Roles do not come into play for public read/write objects.

Public Read Only
Similar to above, this allows for all users to have read access to all records of an object, assuming they have at minimum read access via a profile or permission set. A user will need to have ownership of a record in order to edit it, and also require edit via profiles or permission sets. If a user had read/write access via profile or permission set, they would still not be able to edit a record with Public Read Only access, unless they owned the record.

Private
When an object is set to private, records are only visible (and editable) to users who own the record, assuming they have access to read and/or edit via profile or permission sets. If role hierarchy is enabled, users above owners in the role hierarchy will also have visibility of the record.

Sharing Rules
Sharing rules are used against OWDs (explained above) to open up sharing to certain users via roles or public groups, but only if an OWD is set to Public Read Only or Private. This allows for either read or read/write access to users based on record ownership or record field criteria.

Note: The 'View All' and 'Modify All' permissions on a profile and/or permission set override all restrictive OWD settings, so in certain scenarios Sharing Rules would not be required.

Roles
Roles are used for data visibility within an organisation. For data visibility, roles are only taken into consideration for objects with an OWD set as Private or Public Read Only. Users higher in the hierarchy will have visibility over records owned by people below them (assuming the Use Role Hierarchy option is enabled in the OWD settings).

If a user does not have read or edit access to an object via OWD, a profile or permission set, they will still have no visibility over an object regardless or their role and role hierarchy.

Profiles
Profiles are where permissions for users come into play. A user will never be able to see records in an object, regardless of everything above, if they don't have at least read access set in their profile. This includes create, read, update and delete (commonly called CRUD). The View All and Modify All permissions also override any restrictive sharing above.

Profiles also provide Field Level Security (FLS). This means that profiles can restrict/expose read and edit access to specific fields within objects. A user would require read access on an object before read access on a field can be granted however, as for edit access as well. This provides much more granular access to information than other elements indicated above, which provide access at a object and record level.

Permission Sets
Permission Sets are very similar to Profiles, and offer much of the same functionality. The main difference being, a user can be assigned multiple permission sets, but only one profile. They are useful in providing application and object specific access to users who may serve multiple functions within an organisation, without having to create user-specific profiles. It is generally common practice to keep profiles specific to functions (Sales, Marketing, Operations, Finance), and then provide more granular access to those who might serve across multiple functions.

Public Groups and Queues
Public Groups and Queues are essentially a group of users. One user can belong to multiple groups or queues. They have a subtle difference, in that queues can own records, and groups can not. Groups have slightly different uses for folder and record sharing as well.

Public Groups
Public Groups are quite simply a group of users. A user can belong to multiple groups. Public groups are used again on a restricted sharing model to allow for a certain group of users to have access to records using Sharing Rules.

Queues
Queues are generally used to allow for multiple users to “own” a record. Common use cases are for Cases and Leads, where a number of people may be responsible for actioning a case or lead. Although not directly related to sharing, this is important to understand, because in a “Private” sharing model (OWD setting), a user will still be able to have access to a record if they are part of a Queue that owns a record.

Custom Permissions

Custom Permissions are relatively simple in nature. They essentially provide a way to assign Custom Labels to a profile and/or user. This is powerful if you have custom sharing or permission logic within custom system logic (Apex). An example might be creating a custom permission of "Approve Invoice", which you assign to some users or a profile. In your Apex, you would check if the current user has the Approve Invoice permission, which would then allow them to approve invoices and fire an integration to a back-end invoicing system.

Case Studies and Examples
The rule of thumb is that the most restrictive sharing requirement needs to form the base level of your sharing, and then permissions opened up. For example, if everyone in your organisation should have access to one record, but one person shouldn't, the record needs to be hidden to everyone and then opened up to those who require it. Leaving everyone with access but the one person without.

Another rule of thumb is that for sharing conflicts, the most permissive permission generally wins (with some exceptions). For example, if a profile assigned to a user had no access to an object, but a permission set assigned to that user did, they would have access to the object, because the more permissive sharing would override.

For most sharing requirements, there are generally a few different approaches on how to implement. The goal is to implement sharing that is most robust, scalable and fit for purpose. It is important to keep sharing simple and reduce complexity where possible.

Example time...

1. Everyone in the Manufacturing Team should see all manufacturing opportunities, but only the owner should be able to edit. Anyone outside the team shouldn't see them.

This requirement could be implemented in a few different ways - either using Roles or Public Groups. However, the following settings need to happen:

• Opportunity OWD should be Private. This is because there is at least one user who shouldn't see a certain kind of Opportunity, so the most restrictive setting is required.

• Read, Create and Edit to Opportunities for Profiles (or Permission Set). Because it's likely that all team members will read, create and edit (their own) Opportunities, this access needs to be provided to those users. The actual restriction on editing opportunities they shouldn't is controlled by the OWD above.

• An owner-based sharing rule is required for Opportunities to create Read access to either anyone in the Manufacturing Group or within the Role. Alternatively, if manufacturing Opportunities had a certain record type or value, criteria-based sharing could be used to share to the Group or Role.
   

2. Everyone should see and edit all Accounts, but only Finance can update the Annual Revenue field.

Again, there are a few different approaches we can take here.

• Account OWD should be set to Public Read/Write. Assuming no other restrictions, everyone can see and edit all Accounts.

• Account Read, Create, Edit access is set at Profile and Permission Set level for users who require it.
   

Now for a few different approaches:

1. Two page layouts could be created. One for Finance and one for everyone else. Finance would have the page layout assigned to their profile and the field would be editable. Everyone else has the other page layout assigned and the field is Read Only.

2. Or for one profile set the field to Read Only, for Finance set the field to editable.

3. Or you could set the field as Read Only for everyone, and create a Permission Set that makes the field editable. This Permission Set would be assigned to those who require it.
    

3. Cases should be private to all users (except their managers), until they reach a certain status at which time everyone has edit access. Once closed the case should be read only to all, including the original creator.

This requirement has a number of elements to it. The setup would look as follows:

• Case OWD should be set to Private. Although cases will be more public at a later status, the most restrictive requirement is Private (when a case is first created), so the base rule will need to be so.

• Read, Create and Edit access should be granted to all users who require case access at Profile or Permission Set level.

• "Grant Access Using Hierarchies" should be enabled on the Case OWD settings in order for the user's manager (assumes user's manager is set correctly in the role hierarchy), to also see and edit the cases when they are created.

• Criteria-based sharing rule is created for the Case object which shares read/write access to All Internal Users when the case reaches a certain status.

• Additional criteria-based sharing rule should be created to set sharing to read only to All Internal Users when the case reaches a certain status.

• A validation rule (or "closed" record type with a page layout of all Read Only fields assigned to it) should be created to then block editing of the case once it's closed, so the creator or final owner of the case can no longer edit it.