Data security is a top priority, The stakes are high, your company’s reputation and your customer’s trust are on the line. Users should have all the data they need, but shouldn’t have access to data they don’t need to see. So let’s dive in and explore how to leverage Salesforce Record Access features to ensure you can configure the most complex security models using clicks, not code. You’re well on your way to becoming a record access guru.

Salesforce Security Model Review

Before we dive into Record Access, let’s first have a quick review of the overarching Salesforce Security Model to see where controlling Record Access comes in. 

Before a user can view information on the record, they have to have the right level of access: 

1. Org Access: Have access to the Salesforce org. Ie: Username & Password and if additional security features are enabled, the individual may need to enter a second authentication factor (2FA), or be logging in from a particular IP range, or certain time of day, etc.
2. Object Access: After the user logs in, they will have a specific profile assigned to them that dictates which objects (types of records) they have access to. (Options include: Create, Read, Update, Delete, and No Access)
3. Field Access: Assuming they have at least Read Access to the object, they will only be able to view fields which they have access to. For instance, an employee may have access to the Employee object, where they can see all the employees within the company, but only users within the Human Resource group can view the Compensation field on the record. 
4. Record Access: Assuming the user can login, has access to the object, and access to the fields on that record; you can then granularly control record ownership and sharing. If the user does not have access to any of the layers above, it does not matter what record level security settings or sharing mechanisms you have implemented. Each layer of the Salesforce Security Model Builds on each other. 

Record sharing, the foundation of it all

Org-wide Default

First you start with the Organization Wide sharing Defaults (OWD) which defines the most restrictive record sharing possible for each object. On the Salesforce Platform you can only open up record access from the OWDs, none of the sharing tools can be used to further restrict access — only open it up. So when you are planning your implementation, you have to assess what are the most restrictive requirements around each object and set the OWDs to match, then use record sharing tools to open the access back up. 

Implicit sharing

Implicit sharing is, well, implicit. Meaning automatic. It is important to understand when implicit sharing is operating so you may properly design/implement your security and sharing model. The most common examples of implicit sharing include:

• Record Owner record owners can view all records in their name
• Parent to Child Users with access to a parent account record, can also access its child opportunity, case, and contact records
• Child to Parent Users can view a parent account record if they have access to its child opportunity, case, or contact record

Note: there are some different behaviors for external users (Portal / Community users).

Opening up record access

Building upon the foundation defined above, we will now review six methods for opening up access to an individual record or group of records: 

Manual sharing

The first method is to manually share a record. This requires a Sharing button on the page layout. A user who currently has access to the record, maybe the record owner, will hit the Sharing button, then select who they want to share the record with: 

• User
• Group of Users
• Role
• Territories 

Role Hierarchy

You can share records up a hierarchy. 

For instance, any record shared with the COO, can automatically be shared with the role above him, such as the CEO. 

When you build out your role hierarchy, think of this less like an Org chart, and more like a record sharing hierarchy. Often your Role Hierarchy configuration will closely align with your org chart, but not always. 

Tip: when you build out the lower levels of the hierarchy, group by level of position instead of job title. This will simplify role management. 

Here is an example of role hierarchy in action:

Enterprise Territory management

Grants access to accounts based on account criteria such as postal code, industry, revenue, or custom field. Think of this as a secondary hierarchy sharing tool. With this tool, you can:

• Control access to accounts based on structure territories and automatically share associated Opportunities and Cases
• Speed up mass territory re-alignments by creating draft Territory Hierarchies for review before enabling. 
• Forecast revenue by Territory with Collaborative Forecasting & Territory Management enabled
• Gain a second dimension of reporting with Reports & Dashboards segmented by Territories

A few notes about Territory Management

• You don’t need to enable Territory Management just because you sell in territories, you may be able to simply leverage Role Hierarchy. 
• This is a second sharing mechanism that operates in conjunction with Role Hierarchies. 
• Read through Salesforce’s resources and their Enterprise Territory Management Implementation Guide for more details.

Sharing Rules

Share rules are one of the most powerful declarative tools for opening up access to records. There are two types of rules that can be setup to automatically open up access based on attributes of the record or owner. 

• Criteria Based: Set a rule based on the record’s field data. 
• Owner Based: Create a rule to share records based on the owner. You can select records owned by a Group, Queue, Role, Territory, Portal Role, or Role/Territory & Subordinates. 

When creating a sharing rule, the administrator selects what type of rule, sets the criteria for identifying which records to share, defines what level of access to grant (read, read/write), and then defines who to share these records to (Group, Queue, Role, Territory, Portal Role, or Role/Territory & Subordinates0

Note: you can not share to an individual user. 

Sharing Examples: 

• Criteria Based Sharing Rule: Share all Accounts with a Billing State of “Alaska”, granting Read/Write access, to the Public Group “VP Mangers”
• Owner Based Sharing Rule: Share all accounts and associated opportunities owned by the Eastern Sales Team Role & Subordinates, granting Read Only access to the Western Sales Team Role & Subordinates.

Team Sharing

Many organizations have a team of users assigned to support specific customers. While only one user can own a record, you may consider leveraging team sharing to grant access to all users associated with a particular Account, Opportunity, or Case. 

Each user assigned to the team will have a specific role assigned and you can define what level of access each user/role has to the shared record (Read or Read/Write). 

Teams can be defined for each user, so any accounts/opportunities/cases they create will automatically have the default team assigned. 

Reminder: Keep in mind that when granting access here, like every other sharing mechanism, Role Hierarchy roll ups and implicit sharing will kick in. More people will see your records than just those assigned.

APEX

If you have very complex record sharing requirements and can not find a path to serve your users by layering all the above sharing mechanisms, then you may consider sharing with APEX. But do not make this decision without first thoroughly digging into the above methods and maybe even phoning a friend and posting to the trailblazer community for help. 

There are two forms of sharing with Apex: 

• Apex Generated User Shares 
• Apex Managed Sharing

APEX Generated User Shares are essentially manual shares. When record ownership changes, all these shares are removed.

APEX Managed Sharing: This requires you to fully control the share records under the hood. You have to create custom share reasons and manage the creation and removal of the shares. These share records are not automatically removed when record ownership changes.

Use caution with APEX Managed Sharing. Remember, with great power comes great responsibility. 

More info about Salesforce Record Access

This piece is a quick and dirty overview of the main tools available for record sharing on the Salesforce platform. Of course, there are many nuances and details we could not completely cover in depth, but it should give you an idea of high-level options and serve as a springboard for you to dig further. The salesforce help documentation is a great place to start or if you want to completely nerd out and learn about what is happening under the hood, you may also enjoy the Sharing & Visibility Designer trailmix. 

If you don’t want to do it all yourself, Silverline’s managed services offering is another resource you can lean on. Our team of experienced Salesforce experts can help you navigate record access and then some. Reach out to learn more.