Define Sharing Rules

Learning Objectives

After completing this unit, you’ll be able to:

• Use sharing rules to extend access beyond the role hierarchy structure.
  
• Create a public group that includes users with different profiles and roles.
  

Extend Access with Sharing Rules

Your org-wide default sharing settings give you a (relatively restrictive) baseline level of access for each object. If you have org-wide sharing defaults of Public Read Only or Private, you can open access back up for some users with sharing rules. This enables you to make automatic exceptions to your org-wide sharing settings for selected sets of users. As with role hierarchies, sharing rules can never be stricter than your org-wide default settings. They just allow greater access for particular users.

Each sharing rule has three components—which records to share, with which users, and with what kind of access.

Which Records Are You Sharing?

You can share records owned by certain users or that meet certain criteria for field values.

Which Users Are You Sharing Them With?

You can define groups of users by role, by territory, or by defining a public group. A public group is an admin-defined grouping of users that can be used to simplify the creation of sharing rules. Depending on the group member types available in your org, public groups can be a combination of:

• Individual users
  
• Roles
  
• Roles and subordinates (You can choose whether to include Experience Cloud site and portal users or only internal users.)
  
• Territories
  
• Territories and subordinates
  
• Other public groups
  

What Kind of Access Will They Have?

You can assign either Read-Only or Read/Write access.

Sharing rules work best when they’re defined for a particular group of users that you can determine or predict in advance, rather than a set of users that frequently changes. For example, in the Recruiting app, it’s important to share every position, candidate, job application, and review with every recruiter. Since recruiters all belong to either the Recruiting Manager or Recruiter roles in the role hierarchy, you can easily use a sharing rule to share those objects with the Recruiting Manager role and its subordinates.

Alternatively, consider another use case from the Recruiting app: Interviewers need read access on the candidates and job applications for people they’re interviewing. In this case, the set of interviewers is a lot harder to predict in advance—hiring managers might use different sets of interviewers depending on the position for which they’re hiring, and the interviewers might come from different groups in the role hierarchy. So, this use case probably shouldn’t be handled with sharing rules—the team of interviewers for any given manager is just too hard to predict.

Sharing Rules for the Recruiting App

Let’s go through the access you still want to implement and pick out the ones that work best with sharing rules.

Recruiters need read and update access on every position, candidate, job application, and review record that exists in the app.

Yes. It’s easy to pick out the group of recruiters in your role hierarchy.

Hiring managers need read and update access on position records on which they’re the hiring manager.

No. It’s too hard to predict which positions will be assigned to which hiring manager. You need to handle this use case some other way, such as sharing each position record via a manual sharing rule.

Hiring managers need read access on candidate records on which they’re the hiring manager.

No. Again, it’s too hard to predict which positions will be assigned to which hiring manager.

Hiring managers need read and update access on every job application and review record.

Yes. Since you’re not restricting which job applications and reviews a hiring manager gets to read and update, you can easily pick out all of the hiring managers from your role hierarchy and define a sharing rule for them.

Interviewers need read access on the candidate and job application records for people they’re interviewing.

No. It’s hard to predict who will be a member of an interview team for a particular position.

To summarize, here are the key sharing rules to define for the Recruiting app.

In the rest of this unit, you learn how to create public groups and sharing rules to extend the required access.

What Are Public Groups?

Before creating a sharing rule, it’s important to set up the appropriate public group if you’re using one. A public group is a collection of individual users, other groups, roles, or territories that all have a function in common. For example, users with the Recruiter profile as well as users in the SW Dev Manager role both review job applications. 

Using a public group when defining a sharing rule makes the rule easier to create and, more importantly, easier to understand later, especially if it’s one of many sharing rules that you’re trying to maintain in a large organization. Create a public group if you want to define a sharing rule that encompasses more than one or two groups or roles, or any individual.

Looking at the required permissions that you want to implement for your Recruiting app, there are just two objects that need a public group for their sharing rules: Job Application and Review. Since both recruiters and hiring managers need read and update access to job applications and reviews, you can define a public group called Reviewers that includes both recruiters and hiring managers. In this group, add the SW Dev Manager, Director Product Management, and Director QA roles, and the role and subordinates of the Recruiting Manager.

Create a Public Group

Create the Reviewers public group.

1. From Setup, in the Quick Find, search for and select Public Groups.
   
2. Click New. 
   
3. Enter Reviewers as the Group Label. The Group Name text box populates automatically when you click it. This is the unique name used by the API and managed packages.
   
4. Optionally, add a description.
   
5. Skip adding members for now. Click Save.
   
6. On the Public Groups Setup page, click the Reviewers public group that you just created.
   
7. On the public group’s detail page, click View Summary. On this page, you can see the sharing rules, report and dashboard folders, and list views where this public group is used to grant access, and the other public groups it’s added to. You can also manage its membership.
   

8. Under All Public Group Members, click Add Members.
   
9. Select individual users, other groups, or roles and whether their subordinates are included. You can include a combination of member types in your public groups. For this public group, add these members:
   
   • Role: SW Dev Manager
     
   • Role: Director Product Management
     
   • Role: Director QA
     
   • Role and Internal Subordinates: Recruiting Manager
     
10. Click Save.
    

Once you define your group, you can use it to define sharing rules.

Define a Sharing Rule

For the Recruiting app, you need a rule that shares reviews written and owned by any member of the org with all recruiters and hiring managers

1. From Setup, in the Quick Find box, search for and select Sharing Settings. This is the same page used to define org-wide defaults.
   
2. In the Manage sharing settings for dropdown list, choose the object for which to create the sharing rule. Choosing an object in this dropdown list allows you to focus on the org-wide defaults and sharing rules for a single object at a time rather than looking at all of them on a long page—a useful thing if you have a large org with multiple custom objects. For this rule, select Review.
   
3. In the Sharing Rules area, click New and give your rule the label Edit Reviews. The Rule Name text box populates automatically when you click it.
   
4. For the rule type, you can choose whether the sharing rule is based on the owner or based on criteria that records must match to be included. For this sharing rule, select Based on record owner.
   
5. For Select which records to be shared, select a category from the first dropdown list, and a set of users from the second dropdown list or lookup field. Here, select Public Groups, and then All Internal Users, so that you share all review records.
   
6. For Select users to share with, specify the users who get access to the data. Select the Reviewers public group that you just created.
   
7. Select the sharing access setting. Here, set the access level to Read/Write.
   
8. Click Save.
   

Great job! You opened up access to reviews for the users who need it without changing your org-wide sharing settings.

In this module, you learned all about the four levels of data access and the features and settings used to control them. You even got hands-on practice as you set up access for the Recruiting app. For even more info on managing your users and their access to data, go to Salesforce Help.

Resources

• Salesforce Help: Sharing Rules
• Salesforce Help: Create Sharing Rules
• Salesforce Help: Sharing Rule Considerations
• Salesforce Help: Sharing Rule Categories
• Salesforce Help: Set Up Record Access for Your Users