Sharing Rules in Salesforce

There are various aspects in Salesforce that consider the security of data because there is a large amount of it that is and needs to be shared in companies. This sharing of data requires a check and control to it, which is performed by a set of rules, namely sharing rules in Salesforce.

Confused about Salesforce? Check out this video to learn Salesforce from scratch:

Sharing Rules in Salesforce

Let us consider a scenario wherein there is a manager who is managing two teams, the marketing team in India and the marketing team in the USA. Now, the manager can access both the teams’ records as it can be done through the role hierarchy method, but what if the marketing team in the USA wants to access the records of the marketing team in India. This cannot be done through the role hierarchy method as both the teams are at the peer level. This is where the role of sharing rules in Salesforce comes into play.

Sharing rules help users to share records based on conditions. It is basically created for objects whose organization-wide defaults (OWD) are set to public read-only or private because sharing rules can only extend the access and not restrict it.

In case, if OWD itself is public (read/write), then there is no need to create a sharing rule.

Want to know how to study for Salesforce Admin Certification Exam? Click on the link to get all your doubts cleared.

Types of Sharing Rules in Salesforce

There are basically two types of sharing rules in Salesforce based on which records should be shared:

• Owner-based Sharing Rules
• Criteria-based Sharing Rules

Owner-based Sharing Rules

Owner-based sharing rules in Salesforce are used when we want to share records that are owned by a particular group or a single user with another set of users. For example, if a multinational company (MNC) wants to access the sales record of their US-based office from India, then the owner-based sharing rule is used to access the records shared by the US-based office.

Criteria-based Sharing Rules

Criteria-based sharing rules in Salesforce are used when we want to share records that meet particular criteria or satisfy a particular condition. For example, a bank manager wants to see the records of all savings accounts. In such a case, a filter will be added to the sharing rules, stating that if a particular account belongs to the savings account category, only then will it be shared with the manager.

Preparing for Salesforce Interview? Take a look at Salesforce Interview Questions.

Creating Sharing Rules in Salesforce

Let us take a look at how to deploy a sharing rule in a Salesforce dashboard:

• Step 1:  Go to Sharing Settings, which can be found under the Quick Find section

• Step 2:  Scroll down and find the particular object where a sharing rule needs to be added, and then click on New to create a new sharing rule

• Step 3:  Add the label of the sharing rule you want to make

• Step 4: Choose which type of Sharing Rule you want to create, owner-based or criteria-based

Preparing for a Salesforce Admin Interview! Check out our Top Salesforce Admin Interview Questions and Answers.

• Step 5:  If you have chosen to select records based on criteria, then add the particular criteria to meet the demands of the sharing rule

• Step 6: Select which records are to be shared from the table

• Step 7: Select the users with whom the records are to be shared

• Step 8: Finally, select the level of access to be provided, and click on Save

Your sharing rule is now created.

Components of Sharing Rules in Salesforce

There are three components that make up a sharing rule in Salesforce:

Which Records are to be Shared?

It is determined by the types of sharing rules based on record ownership or whether the indicated criteria are met on a record. The Salesforce administrators need to identify which records are required to be shared with a particular set of users. The administrators need to check whether the records need to be shared by a particular owner or if the records that meet particular criteria are to be shared.

Learn about Salesforce by signing up for this professional Salesforce course in Bangalore!

To Whom Will The Records Be Shared With?

By now, we know what records are to be shared; so, we need to identify which records are to be shared with whom. Is it territory-based groups of users, role-based groups of users, or public groups? Note that public groups are created by admins and could be a combination of:

• Individual users
• Territories
• Territories and subordinates
• Roles
• Roles and subordinates
• Other public groups

Learn more about Salesforce concepts through Intellipaat’s Salesforce training in Coimbatore!

What Access is Provided to Which Record?

The access provided is either read-only or read/write. We need to provide access to the users based on what work needs to be performed on the records. The access, as required, is given by the administrator, be it public read-only or edit access.

When to Use Sharing Rules in Salesforce?

We will discuss specific use cases for sharing rules in Salesforce with two examples based on the selected type:

Record Ownership-based Sharing Rule Use Case

Consider a large department separated into smaller sub-departments such as two or more customer support teams based on the product lines that are serviced by them. The teams should be allowed to view some of each other’s records, such as cases or opportunities, despite the allocation in the role hierarchy under different managers.

In this scenario, using the record ownership-based sharing rule, Customer Support Team A can be allowed to view the records owned by Customer Support Team B, and vice versa.

To learn in-depth about Workflow in Salesforce, sign up for industry-based salesforce training to enhance your knowledge.

Criteria-based Sharing Rule Use Case

Usually, leads, by default, are privately owned records. In some cases, they should be accessible to other people in a company. Let us consider the example of a sales rep who has dealt with a potential client who is not quite ready to buy yet. The lead status is switched to “Unqualified”.

In this situation, the client needs to be convinced to make the purchase. This is where it makes sense to bring in marketing specialists and allow the viewing of such “Unqualified” leads. In this way, the sharing rule will give the marketing specialists access to only the leads they need to view and work with.

Limitations of Sharing Rules in Salesforce

• Sharing rules only provide wider access to other users.
• Sharing rules provide access irrespective of whether a user is active or inactive.
• Sharing rules are always re-evaluated whenever there is a change in roles or users.
• Sharing rules allow users to access any record related to the particular record too, which can lead to losing data integrity.

Know various aspects of Salesforce with the Salesforce tutorial.

Define a Public Group

A public group is a collection of individual users,  individual roles, other groups, and/or roles with their subordinates that all have a mutual function. It can be used by everyone in a company but can only be created by administrators.

The purpose of public groups is to assign things or resources that are intended to be seen or used by everyone in a company. Public groups save a lot of time and effort.

The following are the steps to create a public group if a sharing rule, which encompasses more than one or two groups or roles or any individual, has to be defined:

• In Setup, use the Quick Find box to find Public Groups.
• Click New.
• Label your group. When you click the Group Name text box, it automatically populates. This is the unique name used by the managed packages and API.
• In the Search drop-down list, choose the individual users, other groups, or roles, and whether their subordinates are included. It can be a combination of member types in the public groups.
• Select users in the Available Members list and then click Add.
• Click Save.

Once the group is defined, it can be used to define sharing rules.

Also, check out the blog on Record types in Salesforce.

Define a Sharing Rule

A sharing rule can be defined for a single role, territory, or public group. A sharing rule can also be defined for a role or territory and its subordinates.

• In Setup, find Sharing Settings with the help of the Quick Find box. This is the same page used to define org-wide defaults.
• In Manage sharing settings, choose the object for which to create the sharing rule.
• In the Sharing Rules area, click New and give the rule a label. On clicking the Rule Name text box, it populates automatically.
• For the rule type, choose whether the sharing rule is owner-based or criteria-based. For this sharing rule, select Based on record owner.
• For Select which records to be shared, select a category from the first drop-down list and a set of users from the second drop-down list or Lookup field.
• For Select users to share with, specify the users who should get access to the data.
• Select a sharing access setting.
• Click Save.

Why Are Sharing Rules Required in Salesforce?

Let us understand more about sharing rules in detail. Suppose a chunk of data is required by a number of people in a company, and the integrity of the shared data needs to be maintained throughout. This is where sharing rules come into play. They provide wider access to data and the access specifier can be provided as either read-only or write.

Security in Salesforce

Let us now understand how data security works in Salesforce. There are four ways to provide security in Salesforce:

Above-mentioned is the list of ways and functions that can be performed. Profiles are basically people who can access the data in Salesforce.

Conclusion

Sharing rules are a very efficient way to maintain data integrity in Salesforce, but remember it can only extend the access to other users, it cannot provide restricted access. This is the reason why it provides read-only or read/write access. It works efficiently in those companies that do not allow frequent changes in their list of users.

You can resolve your Salesforce queries in Intellipaat’s Salesforce community.