Use the same account next time to pick up where you left off.
|Production Salesforce account||Developer Edition or Admin Playground|
|Do I need to be a Salesforce customer?||Yes||No (It's free!)|
|Can I use it to create my Trailhead profile and store my badges?||Yes||Yes|
|Can I use it to complete Trailhead challenges?||No (except for multiple choices quizzes)||Yes|
|Can I keep my Trailhead badges if I leave my company?||No||Yes (use a personal email address)|
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.
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.
|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.|
|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|
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.
The New Public Group page allows you to choose other public groups, individual roles, individual roles including the roles' subordinates, or individual users.
Once you’ve defined your group(s), you can use them to define sharing rules.
Suppose you want to use the Reviewers public group to define a sharing rule for review records.
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.
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.
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.
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 using a manual share:
Depending on the data in your organization, your options can include:
|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.|
|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.|
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.
Here are some tips: