Define Sharing Rules
Extend Access with Sharing Rules
Sharing rules can be based on who owns the record or on the values of fields in the record. For example, use sharing rules to extend sharing access to users in public groups or roles. As with role hierarchies, sharing rules can never be stricter than your org-wide default settings. They just allow greater access for particular users.
- Share which records?
- You can share records owned by certain users or meeting certain criteria. Criteria-based sharing rules determine what records to share based on field values other than ownership.
- With which users?
- 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. Each public group
can be a combination of:
- individual users
- roles and subordinates
- territories and subordinates
- other public groups
- What kind of access?
- 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, we 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.
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.
- Yes. As we discussed previously, it's easy to pick out the group of recruiters in our role hierarchy.
- Hiring managers need read and update access on position and job posting records on which they're the hiring manager.
- No. It's too hard to predict which positions will be assigned to which hiring manager. We'll need to handle this use case some other way.
- 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 we're not restricting which job applications and reviews a hiring manager gets to read and update, we can easily pick out all of the hiring managers from our 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. As we discussed previously, 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 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|
Define a Public Group
Using a public group when defining a sharing rule makes the rule easier to create and, more important, 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 we want to implement, 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 Setup, use the Quick Find box to find Public Groups.
The New Public Group page allows you to choose other public groups, individual roles, individual roles including the roles’ subordinates, or individual users.
Give your rule the label Reviewers.
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 Roles.
- In the Available Members list, select SW Dev Manager, Director Product Management, and Director QA, then click Add.
- Go back up to the Search drop-down list, and this time choose Role and Subordinates.
- In the Available Members list, select Recruiting Manager, click Add, and save.
Define a Sharing Rule
- In Setup, use the Quick Find box to find Sharing Settings. This is the same page used to define org-wide defaults.
In the Manage sharing settings for drop-down list, choose
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. Let’s use this Sharing Rules related list to create a sharing rule that applies to both the Job Application and the Review objects.
In the Job Application Sharing Rules area, click New and
give your rule the label Review Records.
The Rule Name text box populates automatically when you click it.
- For the rule type, make sure Based on record owner is selected.
- For Select which records to be shared, select Public Groups, then choose Entire Organization.
- For Select users to share with, select Public Groups, then choose Reviewers.
- For Select the level of access for the users, select Read/Write, then save.