Learning Objectives

After completing this unit, you will 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.
  • Manually share records with other users.

Use Sharing Rules

Your organization-wide default sharing settings give you a baseline level of access for each object. If the default access is too restrictive, you can open access back up to selected users with role hierarchies or sharing rules. Sharing rules represent automatic exceptions to your organization-wide default settings. If you have organization-wide sharing defaults of Public Read Only or Private, you can define rules that give more users access to records they do not own.

You can create sharing rules based on record owner or field values in the record. This enables you to make automatic exceptions to your organization-wide sharing settings for defined sets of users. 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 organization-wide default settings. They simply allow greater access for particular users.

Watch this video to get an overview of the different ways to grant access to records using sharing rules.

Each sharing rule has three components:
  • 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 or by defining a public group. A public group is an administrator-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
  • 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.

Let's go through the set of required permissions we still want to implement and pick out the ones that would work best with sharing rules:
Use Case Should we use a sharing rule?
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.
This table summarizes the key sharing rules we might define for the Recruiting app.
Object Rule Label Owned by... Should be shared 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

Before creating a sharing rule, it’s important to set up the appropriate public group. A public group is a collection of individual users, other groups, individual roles, and/or roles with their subordinates 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 important, easier to understand later, especially if it's one of many sharing rules that you're trying to maintain in a large organization. You'll need to create a public group if you ever 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.

  1. From Setup, enter Public Groups in the Quick Find box, then select Public Groups.
  2. Click New.
    The Sharing Group Membership page for the new group Reviewers. The selected members include those in the SW Dev Manager role and members and subordinates of the Recruiting Manager role.

    The New Public Group page allows you to choose other public groups, individual roles, individual roles including the roles' subordinates, or individual users.

  3. In the Label text box, enter Reviewers. Click in the Group Name text box to populate it automatically. Group Name refers to the unique name used by the API and managed packages.
  4. In the Search drop-down list, choose Roles.
  5. In the Available Members list, select SW Dev Manager, Director Product Management, and Director QA, then click Add.
  6. Go back up to the Search drop-down list, and this time choose Role and Subordinates.
  7. In the Available Members list, select Recruiting Manager, and click Add.
  8. Click Save.

Once you’ve defined your group(s), you can use them to define sharing rules.

Define a Sharing Rule

Suppose you want to use the Reviewers public group to define a sharing rule for review records.

  1. From Setup, enter Sharing Settings in the Quick Find box, then select Sharing Settings. This is the same page used to define organization-wide defaults.
  2. In the Manage sharing settings for drop-down list, choose Job Application.

    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 really useful thing if you've got a large organization with several custom objects.

    If you had chosen Review instead of Job Application, you wouldn’t have the option of creating sharing rules, since you can’t create sharing rules for a detail record in a master-detail relationship. However, since you chose Job Application, a Sharing Rules related list appears. Let’s use that to create a sharing rules that will apply to both the Job Application and the Review objects.

  3. In the Job Application Sharing Rules area, click New.
  4. In the Label text box, enter Review Records.
  5. Click the Rule Name text box to populate it automatically.
  6. For the rule type, make sure Based on record owner is selected.
  7. In the Job Application: owned by members of drop-down list, select Public Groups.
  8. Next to that drop-down list, choose Entire Organization.

    As mentioned earlier, you can define a sharing rule only for a single public group, role, or role with all of its subordinates. By default, the platform includes a default public group that encompasses every user in your organization.

  9. In the Share with drop-down list, select Public Groups.
  10. Next to that drop-down list choose Reviewers.
  11. In the Access Level drop-down list, select Read/Write.
  12. Click Save.
  13. Click OK in the dialog box that says this operation could take significant time.

We just created a rule that shares reviews written and owned by any member of the organization with all recruiters and hiring managers. Since reviewers and hiring managers all need the power to read and update reviews, we handled everyone with a single sharing rule and a public group.

Share Records Manually

A record owner can share individual records with other users by using the Share button on the record. This method of granting access is also known as a manual share. In some cases, granting access to one record includes access to all its associated records. For example, if you grant another user access to an account, the user will automatically have access to all the opportunities and cases associated with that account.

Sometimes it’s impossible to define a consistent group of users who need access to a particular set of records. In those situations, record owners can use manual sharing to give read and edit permissions to users who would not have access to the record any other way. Although manual sharing isn’t automated like organization-wide sharing settings, role hierarchies, or sharing rules, it gives record owners the flexibility to share particular records with users that need to see them. Furthermore, record owners can easily remove the manual shares if the access is not needed anymore.

To grant access to a record, you must be one of the following users.
  • The record owner
  • A user in a role above the owner in the hierarchy (if your organization’s sharing settings control access through hierarchies)
  • Any user granted “Full Access” to the record
  • An administrator

To grant access to a record using a manual share:

  1. Click Sharing on the record you want to share.
    Note

    Note

    The Sharing button is available when your sharing model is either Private or Public Read Only for a type of record or related record. For example, the Sharing button may appear on an account even though your sharing model for accounts is Public Read/Write if your sharing model for related opportunities is Public Read Only.

  2. Click Add.
    The Sharing Detail page for the CA-00002 object
  3. From the Search drop-down list, select the type of group, user, role, or territory to add.

    Depending on the data in your organization, your options can include:

    Type 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.
    Public Groups All public groups defined by your administrator.
    Personal Groups All personal groups defined by the record owner. Only the record owner can share with his or her personal groups.
    Users All users in your organization. Does not include portal users.
    Roles All roles defined for your organization. This includes all of the users in each role.
    Roles and Subordinates All of the users in the role plus all of the users in roles below that role in the hierarchy. Only available when no portals are enabled for your organization.
  4. Choose the specific groups, users, or roles who should have access by adding their names to the Share With list. Use the Add and Remove arrows to move the items from the Available list to the Share With list.
  5. Choose the access level for the record you are sharing and any associated records that you own.
    The available access levels are:
    Access Level Description
    Full Access User can view, edit, delete, and transfer the record. User can also extend sharing access to other users; however, the user cannot grant Full Access to other users.
    Read/Write User can view and edit the record, and add associated records, notes, and attachments to it.
    Read Only User can view the record, and add associated records to it. They cannot edit the record or add notes or attachments.
    Private User cannot access the record in any way.
  6. When sharing a forecast, select Submit Allowed to enable the user, group, or role to submit the forecast.
  7. Select the reason you’re sharing the record so users and administrators can understand.
  8. Click Save.

Manual Sharing in the Recruiting App

After implementing the sharing rules for the Recruiting app, the following required permissions remain:
  • Hiring managers need read and update access on position records on which they're the hiring manager.
  • Hiring managers need read access on candidate records on which they're the hiring manager.
  • Interviewers need read access on the candidate and job application records for people they're interviewing.

It’s difficult to assign these permissions using sharing rules because there’s no way to define a consistent group of users who would need access to a particular set of records. It makes more sense for the person who owns a record to grant access to specific users, when required.

For example, a recruiter, like Mario, who owns the position, candidate, and job application records for jobs he's trying to fill, also knows the hiring manager and interviewers who should be assigned to them. Mario can use manual sharing to grant read or read/write access on records that he owns to any other user, role, or public group.

Although it isn't automated like organization-wide defaults, role hierarchies, or sharing rules, manual sharing gives Mario the flexibility to share particular records with the ever-changing groups of interviewers and hiring managers he works with every day. With this final step, we’ve implemented all of the required sharing and security settings, which we discussed at the beginning of this module, for the Recruiting app.

Share Time Estimate
Topics

Having trouble with your challenge verification?

Here are some tips:

  1. Check for typos (hey, it happens)
  2. Try using a new Developer Edition (existing customizations can interfere with the validation)