Salesforce Sharing Concepts Every Admin Should Understand by Amnon Kruvi

One of the most common questions when it comes to any software that collects data is security and accessibility. In this new era of data protection, it has become more important than ever for system administrators to properly control who gets to see what data.

Perhaps you’ve decided that your marketing team should no longer have access to all of your customers’ purchase history; or that your North American division should stay out of APAC’s business. Maybe you are studying for your Certified Sharing and Visibility Designer exam (in which case, you deserve my sympathies for what you’re about to go through). Whatever it is, you’ve somehow gotten lost on the internet and found yourself reading this article.

Data Access Controls on the Lightning Platform

Before we can discuss sharing concepts, it is important to contextualize it amongst the different types of access controls Salesforce offers:

Object Level Security controls how users can interact with the different data objects in your system. It grants 4 basic abilities on an object-wide level: reading records; creating records; editing records; and deleting records. These, plus sharing access to a record, are required before a user can view or make changes to any specific record belonging to that object.

Field Level Security determines, once the user is able to load a record, which pieces of information the user is able to see. These work on an object level as well, and you cannot define fields to become visible based on certain conditions. You can use field level security to grant access to your sales staff to see a person’s shipping address, but not their birthdate.

Sharing, which is the topic of this article, dictates which users can see which records. While you may give a user object-level security to view leads, this does not have to mean they need to see every lead. Using Sharing, you decide which users are granted access to which leads, accounts, or any other record. Sharing controls whether a user can view, or also edit a record.

Each of these methods works in conjunction with the others to create a complete (arguably) solution to data visibility concerns. For a user to be able to view any piece of information you store, they must have access to it with all three mechanisms.

Granting vs Blocking Access

“How can I block this user from seeing this record?”

This is normally the type of question asked by members of the community before we dive into the topic of sharing. And I have a very firm opinion of this question: it’s wrong.

There isn’t a single data security measure built into the platform that blocks a user from doing anything – instead, they grant users access to data, and only users who have been granted access can see it. The real question becomes:

How can I grant access user A access to this record, but not user B?

This fundamental switch is significant when it comes to designing your organization’s sharing model. It means that once you decide any user shouldn’t have access to a record, you must make the entire object inaccessible to all users, and grant them access again using the available sharing mechanisms. You do this by changing the organization-wide default access to your object to a restrictive option (such as Private or Public Read Only), then re-granting access to the record using sharing rules.

You can perform both of these actions in the Sharing Settings screen, available from the Setup menu.

Setup Your Organization-Wide Defaults

In the above screenshot, we can see the list of objects in our org. Next to each one are two default access selections, one for internal users, and one for external (community or partner) users. By clicking the Edit button, we can change these to one of the available options.

Public Read/Write allows all users to see all records, as well as edit them, given they have the relevant object-level permissions. Some standard objects also have a separate setting for Public Read/Write/Transfer, allowing users to change record ownership from one user to another. The more restrictive option Public Read Only grants all users the ability to see all records, but not modify them, whereas Private grants neither read nor write access.

Some standard objects, like Contact and Activity, have the special option Controlled By Parent. This option grants the same access to the record as the user has to their parent record. If they own an account, they have read and write access to all of its contacts – If they cannot view an account, they cannot view its contacts.

The checkbox on the rightmost column means that access rolls up through the user’s role. If you own an account, your manager has the same access to it as you, and so does their manager. It is important to note that standard objects will always have this option selected, meaning you cannot disable role hierarchy sharing for standard objects like Account and Case.

Use Sharing Rules to Grant Additional Access

By selecting a specific object from the dropdown list at the top, you will be able to create sharing rules. There are two types of rules:

  1. Ownership-based rules allow you to grant access based on the user who owns the record. For example, if you want to share all opportunities between APAC and EMEA, you could create a rule that grants EMEA access to all APAC-owned opportunities, and another one to go the other way.
  2. Criteria-based rules allow you to grant access based on values in the record. For instance, you may decide that the VP of Marketing deserves access to all leads

Both types of rules can share records with users based on the following criteria:

  1. Public Groups are manually-defined groups of users. They pose a maintenance risk if any of these users ever leaves or changes roles.
  2. Roles allow sharing with all users of a particular role in the hierarchy (and those above that role, if hierarchy sharing is enabled for the object).
  3. Roles and Internal Subordinates shares records not only with the role (and possibly their superiors), but also with any role directly or indirectly it. For example, APAC opportunities can be shared with the entire APAC division of the organization, starting at the director and rolling downwards.
  4. Roles, Internal and Portal Subordinates also includes community users

Sharing rules are executed when a change happens to a record, and when you make changes to the rule. You can defer sharing calculation if you plan to make many changes at once, then manually execute a full sharing recalculation.

Above: Creating a sharing rule to share all western sales team accounts with the rest of the team.

Other Sharing Mechanisms

While sharing rules are great at what they do, they only offer a certain resolution of sharing records. To handle other scenarios where more particular sharing is required, Salesforce offers several other mechanisms that allow you to expose data to users:

  • Manual Sharing allows a user who already has access to a record, such as the record owner, give access to another specific user (or users).
  • Account, Case, and Opportunity Teams are lists of users who perform various functions on an account, case, or opportunity level, respectively. While teams can be added to manually, you can also set up Default Teams for your users, in case they regularly work with the same people.
  • Territory Management and Enterprise Territory Management define a territory model (which doesn’t have to be geographical but based on any account attribute). New accounts and their opportunities can be automatically exposed to users who belong to the account’s territory.
  • For the most complicated scenarios, it is possible to set up Apex Sharing. This comes in the form of code, usually a trigger, that creates a record in the target object’s Sharing Table (AccountShare, ContactShare, MyCustomObject__Share, etc). There should also be a batch Apex class that performs a full recalculation. Any records shared with code also need a Sharing Reason, which the system admin defines in the Org.
  • Profile or Permission Set based sharing allows the system admin to grant unlimited read or write access to all records for an entire object – completely bypassing sharing rules and org-wide defaults. These are the View All and Modify All checkboxes, which appear next to the read, edit, create, and delete object-level permissions. There are also two profile permissions named View All Data and Modify All Data, which grant access to all records in all objects. This is typically reserved for system administrators.

These methods should, theoretically at least, cover all sharing scenarios.

Role Hierarchy and Record Sharing

Your org’s role hierarchy plays an important part in determining who has access to what data. For all standard objects, as well as the default for custom objects, a user’s manager can see anything the user can see.

Let’s pretend Zack is a sales agent. Zack is part of a team of ten, who all report to Becky. In their org, opportunities are private, so Zack can only see his own sales and none of his teams’. Becky, on the other hand, can see her own opportunities, but also those of the entire team. Becky’s manager can see hers, and so on.

Should the administrator wish for the rest of Zack’s team to see his data, they would have to set up a sharing rule to share the records with other users in the same role.

If you are planning on taking the Sharing and Visibility exam, do make sure you are very clear on this topic. Many questions focus on role hierarchy and which records will be visible to which users.

Implicit Sharing

There are some instances where a user can view a private record without being granted access to it. When you have access to a record, you automatically receive access to read its parent record (if you can see a contact, you can see its account). The same is true for seeing child records. This concept is called Implicit Sharing, and only ever provides read access (never write access).

Here is a little more on implicit sharing.

Fantastic Sharing Woes and How to Dodge Them

Let’s clarify something: every time you save a record, there are a lot of checks being performed to determine who deserves access to it. Sharing rules, territory, even Apex code – and all of these take time and resources. And when you make certain changes to a user, like changing their role? Now everything needs to be recalculated to see what the user does and does not have access to.

During this period, the record you are changing, as well as its parent and sibling records (records owned by the same parent) are locked. While records are locked, any other changes made to them are denied – resulting in an error. In a multi-user environment, this can quickly become a problem.

Therefore, when defining a sharing model, the goal is to minimize the time it takes to calculate access. But how does one do that?

  1. Avoid Ownership Skew – that’s when one user owns lots and lots of records on the same object, like an integration user creating lots of records without assigning them to a new owner. The rule of thumb is not to go over 10,000 records per user. If you must have ownership skew, then at the very least that user should be at the ‘top’ of the role hierarchy, so sharing does not roll up to other users.
  2. Avoid Data Skew – when a single parent record has many child records, such as having a dummy account to hold all your contacts. The same recommendation of 10,000 records per parent applies.
  3. Whenever possible, use Public Read/Write org-wide defaults. Sharing is essentially disabled for public objects – so the risk is entirely mitigated.
  4. Avoid high-risk operations as detailed in the Record Locking Cheat Sheet. Some objects, like account, have a cascading effect on sharing – making changes of record ownership a slow operation.
  5. When making large changes, such as a big data import, mass changes to record ownership, role hierarchy, or redefining sharing rules, temporarily defer (pause) sharing. Enable them afterward to recalculate all the changes.

Sharing in Communities

Communities are designed to host millions of users, which presents entirely new challenges when it comes to handling a responsive sharing architecture. This is partly the reason why regular community user licenses do not support the standard sharing mechanisms built into Salesforce – not even sharing rules. Instead, Customer Community User licenses utilise two entirely new mechanisms:

  1. Sharing Sets determine what records are shared with community users. Sharing sets operate on the principle that a user is related to a contact, which is related to an account. Records can be exposed if they are related (directly or indirectly) to the user’s contact or account. For example, a user can see the cases that he or she raised because they are related to the same contact.
  2. Sharing Groups determine who can see records owned by community users. For example, European users who raise cases could have those cases shared with EMEA support agents.

Sharing sets and groups are configured in Communities Settings, rather than the standard sharing configuration page. It is noteworthy that only one sharing set can be created per community profile.

Customer Community licenses are designed to support up to 10 million users in a single Salesforce org – however, that is not the only type. Two other licenses exist for communities:

  1. Customer Community Plus users have greater access to sharing features. They can have up to 3 roles, and therefore are able to utilize sharing rules.
  2. Partner Community licenses feature the same benefits as Customer Community Plus and also have access to sales-related objects (leads, campaigns, and opportunities).

Both of these license types support up to 1 million users. As of the Summer 18 release, sharing sets are also available for these two types of licenses in addition to sharing rules (as a beta feature).

Tip of the Iceberg

Sharing, as most security-related topics, is a huge subject with many nuances. It is the job of every admin to do the best they can to secure their data, and I can only hope this article can help get someone started in the right direction. If you are planning to take the exam, keep in mind that it is long, difficult, and rather mind-bending – real-life experience is highly recommended.

And of course, no matter how difficult they are to master, it’s always better to have these features available when you need them.