Licenses

Full Sharing Model Usage Users/Licenses

Most Standard Salesforce license types take full advantage of the sharing model components. For example, the Force.com Free edition.

High Volume Customer Portal License

High Volume Customer Portal (HVPU) license users (including Community and Service Cloud license users) do not utilize the sharing model. HVPU licenses have their own sharing model that works by foreign key match between the portal user (holding the license) and the data on Account and Contact lookups. HVPU license is only used for the Customer Portal and not the Partner Portal.

Chatter Free License

Have no access to CRM records, thus no sharing.

Components

Profiles and Permission Sets

• Object-level security
• Field-level security

Record ownership and Queues

If a single user owns more than 10,000 records, as a best practise:

• Either the user record of the owner should not have a role in the role hierarchy
• Or the user is at the top of the hierarchy in its own branch of the role hierachy

Organisation-Wide Defaults

The only way to restrict user access to a record.
For custom objects only, use the Grant Access Using Hierarchies setting, which if unchecked (default is checked), prevents managers from inheriting access. This setting is found in the organization-wide default settings.

Role Hierarchy

An organization is allowed 500 roles; however, this number can be increased by Salesforce. As a best practice, keep the number of non-portal roles to 25,000 and the number of portal roles to 100,000.
As a best practice, keep the role hierarchy to no more than 10 levels of branches in the hierarchy

Use Cases

• Management access – the ability for managers to be able to see and do whatever their subordinates can see and do.
• Management reporting – the ability for reporting to roll up in a hierarchical fashion so that anyone higher in the hierarchy sees more data than those below them.
• Segregation between organizational branches – different business units don’t need to see each other’s data; having a hierarchy in which you can define separate branches allows you to segregate visibility within business units, while still rolling visibility up to the executive levels above those units.
• Segregation within a role – in many organizations/applications, people who all play the same role should not necessarily see each other’s data. Having hierarchical roles allows you to define a “leaf” node in which all data is essentially private, and still roll that data up to a parent role that can see all.

Public Groups

As a best practice, keep the total number of public groups for an organization to 100,000.

Use Cases

• Provide access to an arbitrary group of people, you create a public group to collect them, and then use other sharing tools to give the group the necessary access. Group membership alone doesn't provide data access.
• A nested group to gain the same access as the group in which it is contained.
• Groups also have the ability to protect data shared in the group from being made accessible to people in the role hierarchy above the group members.

Ownership-based Sharing Rules

Give additional users access to records they don’t own outside the scope of organization-wide default and role hierarchy settings.
Don't apply to private contacts.
As a best practice, keep the number of ownership-based sharing rules per object to 1,000.

Use cases

• Role-based matrix management or overlay situations: a person in Service needs to be able to see some Sales data, but they live in different branches of the hierarchy, so you can create a rule that shares data between roles on different branches.
• To provide data access to peers who hold the same role/territory.
• To provide data access to other groupings of users (public groups, portal. roles, territories). The members of the groupings who own the records can be shared with the members of other groupings.

Criteria-based Sharing Rules

Criteria-based sharing rules provide access to records based on the record’s field values (criteria).
As a best practice, keep the number of criteria-sharing rules per object to 50; however, this can be increased by Salesforce.

Manual Sharing

When it’s impossible to define a consistent group of users who need access to a particular set of records, use manual sharing to give read and edit permissions to users who would not have access to the record any other way.
Manual sharing is removed when the record owner changes or when the sharing access granted doesn't grant additional access beyond the object's organization-wide sharing default access level. This also applies to manual shares created programmatically.

Team

A team is a group of users that work together on an account, sales opportunity, or case. Record owners can build a team for each record that they own. The record owner adds team members and specifies the access level each team member has to the record. Some team members can have read-only access, while others have read/write.
Only owners, people higher in the hierarchy, and administrators can add team members and provide more access to the member. A team member with read/write access can add another member who already has access to the record with which the team is associated. The team member can't provide them additional access.
Creating a team member in the app creates two records: a team record and an associated share record. If you create team members programmatically, you have to manage both the team record and associated share record. There is only one team per record (Account, Opportunity or Case). If multiple teams are needed, depending on your specific needs consider territory management or programmatic sharing.
The team object is not a first-class object, thus no custom fields, validations rules, or triggers for teams.

Use cases

• The user with the ability to give access (read-only or read/write) to a single group of users (the team).
• If teams are managed externally, say through an external commission or territory management system, then integration can be used to manage the account team. There are cases when territory management in an external system can align to a team solution within Salesforce
• Multiple owners of an account can be managed by the account team
• A single group of users (team) require either read-only or read/write access to an opportunity record. (Opportunity Team).

Territory Hierarchy

A single dimensional, additional hierarchy which can be structured by business units or any kind of
segmentation in a hierarchical structure. When enabled you must manage both the role hierarchy and territory hierarchy.
Territories exist only on Account, Opportunity and master/detail children of Accounts and Opportunities. Organizations can have up to 500 territories; however, this number can be increased by Salesforce. As a best practice, keep the territory hierarchy to no more than 10 levels of branches in the hierarchy.

Use cases

• Multiple groups of people (multiple teams) require either read-only or read/write access to accounts.
• An additional hierarchical structure (different from the role hierarchy) is needed.
• A single user needs to hold multiple levels in the hierarchy.
• Global users (GAM – global account manager) need to see everything from the global account downward.

Account Territory Sharing Rules

Available only when Territory Management has been enabled for an organization

Use cases

• To provide data access to accounts within a territory (not based on ownership) to a grouping of users. Applies only to accounts and when territory management is enabled.

Programmatic Sharing

Last resort to share data.

Use cases

• No other method of sharing (declarative) meets the data access needs.
• There is an existing, external system of truth for user access assignments which will continue to drive access and be integrated with Salesforce.
• Poor performance by using native sharing components. (Usually applies to very large data volumes)
• Team functionality on custom objects.

Implicit Sharing

Implicit sharing is automatic and not a configurable setting.
Parent implicit sharing is providing access to parent records (account only) when a user has access to children opportunities, cases, or contacts for that account. Salesforce has a data access policy that states if a user can see a contact (or opportunity, case, or order), then the user implicitly sees the associated account.
Child implicit sharing is providing access to an account’s child records to the account owner. This access is defined at the owner’s role in the role hierarchy. Child implicit sharing only applies to contact, opportunity, and case objects (children of the account). The access levels that can be provided are View, Edit, and No access for each of the children objects when the role is created. By setting
to View, the account owner can implicitly see the associated object records (contact, opportunity or case). By setting to Edit, the account owner can implicitly modify the associated object (contact, opportunity or case). Implicit sharing doesn't apply to custom objects.

Customer Implementation Scenarios

Customer Scenario: Team Assignment Managed Externally via Customer Master System

Requirements/Challenges	Solution
Two in a box: a sales manager of one geographic coverage area also wants access to another geographic coverage area in order to assist.	Ownership-based Sharing Rule: An ownership-based sharing rule works here because these are edge cases and not the norm. It is also acceptable if the ownership-based sharing rule provides more access than is truly necessary because this is a manager – a trusted individual.
Country-based operations users need access to all country sales data.	Ownership-based Sharing Rule: A very common use of a sharing rule is when a different department (other than sales) needs access to sales data
At least 80% of the time, there is a “core 4” team on an account (Account Executive, Inside Sales Rep, Sales Consultant, Technical, Sales Rep). The system of record for the account team assignment is external to SFDC. There is always only one team to an account.	Teams (Account and Opportunity): Since there is always only one team per account, even if there are many different members with different roles, the account team functionality satisfies this requirement
Managers of the team should have the same access as their subordinates	Role Hierarchy: The role hierarchy solves this by allowing managers to have access to the data of their subordinates.
The assigned account team should not be modifiable.	Teams (Account and Opportunity): This is not actually accomplished with the account team functionality, however, it also shouldn’t prevent you from still using account teams. There are multiple ways of locking down the teams, however, for this case, removing the account team page layout is used.
There needs to be “buddy” functionality so that when someone is sick or on vacation, someone without standard access to an account or opportunity can be accessed and covered during the time off.	Teams (Account and Opportunity): A “buddy” can simply be a role on the team that accomplishes this requirement. However, the challenge comes from the previous requirement where Teams should not be modifiable. The only solution is to have a set group of people who can modify teams within SFDC to create the buddy role when necessary.
When a deal requires a custom solution, additional people (who are not necessarily in the sales organization) need to have access to the deal.	Teams (Account and Opportunity): A pretty standard usage of the Opportunity Team accomplished by manually adding a new member to the Opportunity Team (via related list). Can also be accomplished via a trigger if you always know who should be added. In this case, it is opportunity by opportunity.

Customer Scenario: Out-of-box Territory Management

Requirements/Challenges	Solution
Two different opportunity teams from two distinct business units (Retails Sales and Remarketing) need access to the same account record. They should share contacts and be aware of all activities on the account. These two business units have their own hierarchy and rollups	Territory Management: The best way to think of this is having two branches of a hierarchy that may be structured very differently. What justifies territory management is that there are two levels of these two different branches (both levels with members = the opportunity team for that business unit) who need access to the account. Although you could have accomplished this with a Teaming concept, that was too granular. The sales segmentation was not a an account level but in a hierarchy.
There is a separate group of business developers who are assigned and need access to specific accounts for a specific opportunity team (a territory). The business developers are shared resources for the opportunity teams which mean each business developer may be assigned to one or more accounts for one or more opportunity teams.	Territory Management: Because this is a group of users (or a team), and each business development team could be different by accounts, and since terrotory management was needed for another reason, then the likely best approach is to build out sub-territories that represent these business development teams.
There are non-commission based sales supporting roles who need access to accounts on a one off basis.	Teams (Account and Opportunity): The key portion of the requirement is “one off basis”. This means it is done on an account by account basis so account teams provide that natively.
The credit department needs access to all accounts for a given business unit	Ownership-based Sharing Rule: This is a situation where across the board, for a given business unit, a group of users needs to see everything. This could be accomplished with a sharing rule for a role the group belongs to, a branch of the role hierarchy the group belongs to (role and subordinates) or even a public group.
Managers should have the same access as their subordinates.	Role Hierarchy: The role hierarchy solves this by allowing managers to have access to the data of their subordinates.

Consideration

Territory management is not reversible.

Role Hierachy

No impact. Flatten it as much as possible. Don't make it identical as territory. Use it for non-sales hierarchy.

Teams

Can still be used but as last resort.

Realignment and Reassignment

There are two types of changes that will occur – the membership of roles, teams, or territories, and the structure of the hierarchy. Membership changes can typically occur daily, even hourly. Hierarchy structural (realignments) changes generally occur less often (quarterly, semi-annually, or annually) and can be resource expensive.

Large Data Volumes

Testing out your changes in a sandbox is highly recommended before production. This will also give you a baseline for how long the change will take.
If you have more than two million accounts, and have implemented teams or Territory Management, you especially need to pay attention to performance. These are complex sharing model components that can make for a huge volume of share records and hence, long running transactions.

Defer Sharing Calculations

There is a feature that can be enabled by Salesforce Support to defer automatic sharing calculations.
By suspending these temporarily, you are able to make the change and then have sharing calculations happen all at once. This is typically a more efficient and better performing method to bulk changes.

Data Skews/Ownership Skews

Data skews are defined as a few parent records with many children records. This can really hurt you when a few accounts have many
contacts, opportunities, or cases. The ratio where we start seeing performance degradation is 1:10,000. As a best practice, keep the ratio as close to that as possible (lower is preferred).
Ownership skews are similar to data skews, except if we are referring to a single user, role, or group owning a large number of records for an object. As with data skews, these can also cause long running transactions, causing a performance degradation when change occurs. The recommended ratio of owner to number of records is also 1:10,000.
If a single user owns more than 10,000 records, as a best practice:

• The user record of the owner should not hold a role in the role hierarchy.
• If the owner's user record must hold a role, the role should be at the top of the hierarchy in its own branch of the role hierarchy

The Account Hierarchies Impact on Data Access

The simple fact of only having a parent/child relationship between two records does not drive access. Although the role hierarchy and the territory hierarchy do work in this way, the account hierarchy does not.

Troubleshooting

Troubleshooting flow:

1. Verify that the user has permissions to access to the object.
2. Identify the user's role who can't see the record and note it.
3. Identify the owner's role of the record and note it.
4. Review the role hierarchy and verify these two roles are in two different branches (they should be).
5. Now you need to review the sharing rules for the object and make sure there is no rule that will grant the user access. This can also cause you to look in public groups as well. Maybe the user just got left out of a group where there is a sharing rule, or does it make sense to create a new sharing rule to grant the user access? This depends on the architecture you are trying to maintain, and applies to both ownership-based sharing rules and criteria-based sharing rules.
6. If you are using teams, should this user be on the team for that record? How are teams maintained and how did the miss occur?
7. If manual sharing is used, the user may have lost access because the record owner changed. Manual shares are dropped when ownership changes. The manual share could also have been removed using the Share button.
8. If you are using territory management, is the user missing from one of the territories? Where is the membership of territories maintained and how did the miss occur? Or, maybe the record did not get stamped with the territory where the user is a member.
9. If you are creating programmatic shares and there are criteria for creating the share in code, review the code to understand why this user was omitted.