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.
Each sharing rule has three components.
- 1. 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.
2. With which users?
You can define groups of users by role 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
- roles and subordinates
- other public groups
3. 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.
Example of where to use sharing rule :
1.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.
2. 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.
3.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.
When you define a sharing rule, you can choose from the following categories in the owned by members of and Share with drop-down lists. Depending on the type of sharing rule and the features enabled for your organization, some categories may not appear.
| CATEGORY | DESCRIPTION |
|---|---|
| Managers Groups | All direct and indirect managers of a user. |
| Manager Subordinates Groups | A manager and all direct and indirect reports who he or she manages. |
| Queues | All records owned by the queue, excluding records owned by individual members of the queue. Available only in the owned by members of list. |
| Public Groups | All public groups defined by your administrator.
If a partner portal or Customer Portal is enabled for your organization, the All Partner Users or All Customer Portal Users group displays. These groups includes all users allowed to access your partner portal or Customer Portal, except for high-volume portal users. |
| Roles | All roles defined for your organization. This includes all of the users in the specified role. |
and more …
You can’t include high-volume portal users in sharing rules because they don’t have roles and can’t be in public groups.
Criteria Based Sharing Rule
Criteria-based sharing rules determine whom to share records with based on field values in records. For example, let’s say you use a custom object for job applications, with a custom picklist field named “Department.” A criteria-based sharing rule could share all job applications in which the Department field is set to “IT” with all IT managers in your organization.
This training blog is very useful to learn about sharing rules in saleforce.