Sharing rules - Sharing rules offer access more than the set privileges, which can extend beyond what you get through role hierarchy settings. Regardless of their role in the hierarchy, sharing rules extends access to records to users created by System Administrators. Sharing rules are like expanding access horizontally whereas role hierarchies are vertical expansion of the access. So if you want to grant access to teams who are in the same role you may need sharing rules on rock.
When an Object's OWD is set to Public Read Only or Private via sharing rules, access can be granted to users.
-
1. When OWD is set to Private, then Read or Read/Write access can be granted
-
2. When OWD is set to Public Read Only, then Read/Write access can be given.
Types of Sharing Rules:-
Owner Based - Based on the owner of the record.
Criteria Based - Based on field values of record
Record accesses are granted by sharing rules to the following users or groups as shown below:
-
1. Public Group
-
2. Roles
-
3. Roles and Subordinates
-
4. Queues
-
5. Portal Roles
-
6. Portal Roles and Subordinates
-
7. Roles, Internal and Portal Subordinates
-
8. Territories
-
9. Territories and Subordinates
Generally, users compare permission set with sharing rules and assume permission sets can be used to open up access to a specific group of people. However, this can only be achieved by using sharing rules. Permission sets extend profile permissions to users, such as creating, editing or deleting records, etc.
Guest user criteria-based sharing rules are an additional type of sharing rule available to give record access to guest site users as per the record field values.
If your organization has User Sharing enabled, you can control who sees whom in the organization, including internal and external users.
External users such as high-volume experience cloud site users who don't have roles can't be used in sharing rules.
Sharing Rule Considerations -
-
1. You can use sharing rules to grant wider access to data.
-
2. Sharing rules can be created when your organization-wide defaults must be Public Read Only or Private. That makes sense!
-
3. The user gets the permissive access level when multiple sharing rules give a user various privileges on a record.
-
4. Additional access to related records will be done automatically via sharing rules.
-
5. Users below in the role hierarchy will share the same access as the user above them in the role hierarchy automatically from a sharing rule, the prerequisite to this is that object is either a standard object, or it has access using the hierarchy option enabled
-
6. Users who support roles not having licenses can only be a part of some types of sharing rules, both in receiving access and having records they own to be shared.
-
7. You're not allowed to involve a high volume community, site users, Chatter External, and Chatter Free users in the owner based sharing rule.
-
8. High-volume user-owned records can be shared via criteria-based sharing rules.
-
9. Org or app maintenance users such as Automated Process and License Manager users can participate in criteria-based sharing rules. Such types of users cannot be included in owner based sharing rules.
-
10. In criteria-based sharing rules use of encrypted fields is not allowed.
Manual sharing - Manual sharing, as the terminology itself suggests, involves sharing the record with a user, role or group manually, meaning just by clicking the share button on the record. In organizations using a private sharing model, there may be some situations where only access to one or two records are required then why to open up major access? This is where manual sharing comes into play, unlike having account teams or opportunity teams enabled.
How does Manual sharing change the life of a user?
-
1. Firstly, how does manual sharing get enabled in the environment? Always keep in mind that to legalize manual sharing, the object's sharing model or the OWD should be private. The "Manual user record sharing" should be enabled in the sharing settings.
-
2. Secondly, what one can do to make the "Sharing" button visible on the layout - Go to the setup -> Object Manager -> Search for any object for whom the sharing has to be enabled say- Account -> Go to its page Layout -> click on edit and navigate to the page layout field picker -> then click on Mobile and lightning actions -> finally drag the sharing button onto the Salesforce Mobile and Lightning Experience Sections -> TaDaaaa!! You have added the Sharing button.
-
3. Now to whom you can share the records to - Go to the required record which needs to be shared -> click on the sharing button -> You will be navigated to the page shown below.
-
4. Now click on Add button, you will be navigated to the page below
Now, you can share the record with a public group or with people belonging to a particular role or with a group of people belonging to a specific role and their seniors or with the individual users.
-
5. Who is allowed to share the record manually? - Obviously, not everyone in the environment can share anybody's record with anyone; there are some limitations around who is eligible to share the record using manual sharing in salesforce.
- 1. The Owner of the record
- 2. A user who stands above the record owner in the Role Hierarchy. E.g. a senior manager could share managers records(assuming the role hierarchy is set up as such)
- 3. System Administrator for sure
- 4. Any user with full access to the record
Now I want to bring your attention on something very useful, there are two types of individual record sharing, Manual sharing & Team sharing
Team sharing Specifically done for sales Team, which can include Sales Specialist, Sales Engineer, Sales Representatives basically Team Sharing focuses on all those people who come together in a business, be it for closing a deal, be it for providing a service on a product or be it for providing the service to our potential customers or the customer itself. Manual Sharing specifically done on custom objects. There are 3 types of Team Sharing is Salesforce:-
-
1. Account Teams
-
2. Opportunity Team
-
3. Case Team
You can remember these teams in a rhyme say -TACO. Account Teams is a group of users who work on an account together, Account team does not claim itself the owner of any Accounts, the access needed by the account Team members should be viewed or Edited at the object level, the access granted by the account team are on account itself, related opportunities, contacts or cases
When there is a need to define an Account Team?
More than one user needs to work on the same account, organization is facing the sharing limits, if the owner needs to manual share the account
What are default account teams?
This type of account Team is set on the individual's user record, which may include user managers or any business expert, once defined on the user record you can just add this default team through the account Team related list on account make sure each member added in the team has a role assigned.
What is Team Selling - Team selling is also known as opportunity team where few members or say sales people come together to close the deal with the customer, this Team also follows as of account Team, the only difference is we only define opportunities access and no focus on its related object's access , for example, when the OWD for an account and contacts are said to be private and the organization has a large and complex sales distribution, this is when teams are defined.
Since due to the private sharing model often these users might need the account owners or opportunity owner to manually share the record access and thus to avoid this manual sharing we can simply enable account team or opportunityTeams in the system.
Question to you what do think about public groups and these team sharing let me know in the comments
Case Team is a team or group of people, solving the case together. Typical members can be support managers and product managers . Admin can set up case teams where you add people on the related list of cases. Adding a Team Member needs to have a predefined role similar to account and opportunity team roles determine the level of access a group members achieve on the case be it Read or Read/Write. We can add contacts as well to the case team, but they can only access cases under one scenario - when they’re enabled as customer portal users who are assigned to case page layouts. Moreover, customer portal users cannot update case teams or view roles of case team. When it comes to partner portal, case teams aren’t available.
Admins can predefine case teams. This helps you add people with whom you frequently work with. They can create assignment rules that add predefined teams to cases, matching specific criteria. Moreover, they can also create email alerts that notify team members when an action happens on a case.
