Define Sharing Rules
Learning Objectives
Extend Access with Sharing Rules
- individual users
- roles
- roles and subordinates
- territories
- territories and subordinates
- other public groups
Should we use a sharing rule?
Let's go through the set of required permissions we 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.To summarize, here are the key sharing rules we define for the Recruiting app.
Object | Rule Label | Owned by... | Share with... | Access Level |
---|---|---|---|---|
Review | Edit Reviews | Entire Organization | Recruiters and Hiring Managers | Read/Write |
Candidate | Edit Candidates | Entire Organization | The role and subordinates of the Recruiting Manager | Read/Write |
Position | Edit Positions | The role and subordinates of the Recruiting Manager | The role and subordinates of the Recruiting Manager | Read/Write |
In the rest of this unit, you'll learn how to create public groups and sharing rules to implement these permissions.
Define a Public Group
- From Setup, in the Quick Find, enter Public Groups, and then select Public Groups.
- Click New.
- Give your group a label. The Group Name text box populates automatically when you click it. This is the unique name used by the API and managed packages.
- In the Search drop-down list, choose from which individual users, other groups, or roles you’ll select users, and whether their subordinates are included. You can include a combination of member types in your public groups.
- In the Available Members list, select users, then click Add.
- Click Save.
Once you’ve defined your group, you can use it to define sharing rules.
Public Groups for the Recruiting App
Looking at the required permissions that we want to implement for our Recruiting app, there are just two objects that need a public group for their sharing rules: Job Application and Review. The good news is that we can cover these objects in a single group because the Review object is on the detail side of a master-detail relationship, so it inherits the sharing settings we apply to the Job Application object.
Since both recruiters and hiring managers need read and update access to job applications and reviews, we can define a public group called Reviewers that includes both recruiters and hiring managers. In this group, we add the SW Dev Manager, Director Product Management, and Director QA roles, and the role and subordinates of the Recruiting Manager.
Define a Sharing Rule
- From Setup, in the Quick Find box, enter Sharing Settings, and then select Sharing Settings. This is the same page used to define org-wide defaults.
- In the Manage sharing settings for drop-down list, choose the object for which to create the sharing rule. Choosing an object in this drop-down list allows you to focus in on the org-wide defaults and sharing rules for a single object at a time rather than looking at all of them in a long page—a useful thing if you've got a large org with multiple custom objects.
- In the Sharing Rules area, click New and give your rule a label. The Rule Name text box populates automatically when you click it.
- 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.
- 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.
- For Select users to share with, specify the users who get access to the data.
- Select a sharing access setting.
- Click Save.