Learning Objectives

After completing this article, you’ll be able to comprehend:

Licensing

License

If the license does not have access to CRM records (standard or custom objects) and content functionality, sharing is not available. Example Chatter Free License.

Note: Sharing will only be applicable if the assigned license, enables access to the feature in question.

Org-wide defaults

Determines access and permission for users who do not have access to records.

External org wide defaults is limited to Users/Partners/Partner communities
External access for an object cannot be more permissive than internal access
Transfer permission only available to Leads and cases (can be transferred without ownership).

Territory Management And Teams

Only users with “Modify All Data” permission can add or change Apex managed sharing on a record.
Apex managed sharing is maintained across record owner changes.
A manual share access level is set to Read and you insert a new one set to Write. The original share rows are updated to Write, indicating the higher level of access.
Sharing granted to users implicitly through organization-wide defaults, the role hierarchy, and permissions such as the “View All” and “Modify All” permissions for the given object, “View All Data,” and “Modify All Data” are not tracked with this object.
Apex sharing reasons and Apex managed sharing recalculation are only available for custom objects.

Platform Encryption

Field Audit Trail

Record-Level Access: Access Grants

When an object has its organization-wide default set to Private or Public Read Only, Salesforce uses access grants to define how much access a user or group has to that object’s records.

Contacts that aren’t linked to an account are always private. Only the owner of the contact and administrators can view it. Contact sharing rules don’t apply to private contacts.
If the org-wide default is set to Public Read/Write/Transfer for cases or leads, only the record owner or administrator can delete the record.
If a user transfers ownership of a record, Salesforce deletes any manual shares created by the original record owner, which can cause users to lose access. When account ownership is transferred, manual shares created by the original account owner on child records, such as opportunities and cases, are also deleted.
To restrict users’ access to records they don’t own that are associated with accounts they do own, set the appropriate access level on the role. For example, you can restrict a user’s access to opportunities they don’t own yet are associated with accounts they do own using the Opportunity Access option.
Regardless of the organization-wide defaults, users can, at a minimum, view the accounts in their territories. Also, users can be granted access to view and edit the contacts, opportunities, and cases associated with their territories’ accounts.
The organization-wide default settings can’t be changed from private to public for a custom object if Apex code uses the sharing entries associated with that object. For example, if Apex code retrieves the users and groups who have sharing access on a custom object Invoicec (represented as Invoiceshare in the code), you can’t change the object’s organization-wide sharing setting from private to public.

Who Has Access to Account Records? A user can have access to an account from:

Record ownership
Implicit access from an associated child record such as a case, contact, or opportunity
Organization-wide sharing defaults
Role hierarchy
Sharing rules
Manual sharing
Account team or territory

Guidelines for user access to a record

Record owner = Record owners always get access to their own records.
Implicit access = Corresponds to the “Associated record owner or sharing” entry in the Reason column of the Sharing Detail page. The user may have access to a child record of an account (opportunity, case, or contact), which grants them Read access on that account. You can’t overwrite this access. For example, if the user has access to a case record, he or she has implicit Read access to the parent account record.
Role hierarchy = The user may have inherited Read access from a subordinate in the role hierarchy. You can’t override this behavior for non-custom objects. If the user who has access is on a different branch of the hierarchy from the account owner, check the sharing rules, account teams, and account territory.
Sharing rules = The user may have gotten access because he or she has been included in a relevant sharing rule. If the sharing rule uses public groups (or other categories such as roles) to grant access, check your public groups to see if the user has been included in the group.
Manual shares = The user may have gotten access through the Sharing button of the record. Only the record owner, an administrator, or a user above the owner in the role hierarchy can create or remove a manual share on the record.
Account Teams and Territory = The user may have been added to an Account Team by the account owner, an administrator, a user above the owner in the role hierarchy, or an account team member. If your organization uses territory management, check if the user who has access is higher in the territory hierarchy than the account owner. Managers gain the same access as their subordinates. Additionally, if the user is a member of Group A, which is a member of Group B, he or she gets access to all accounts shared to Group B, at the same level of access as members of Group B.

When you update organization-wide defaults, sharing recalculation applies the access changes to your records. If you have a lot of data, the update can take longer.
If you’re increasing the default access, such as from Public Read Only to Public Read/Write, your changes take effect immediately.
Sharing recalculation is then run asynchronously to ensure that all redundant access from manual or sharing rules is removed.
When the default access for contacts is Controlled by Parent and you increase the default access for accounts, opportunities, or cases, the changes take effect after recalculation is run.
Decreasing the default access, such as from Public Read/Write to Public Read Only, your changes take effect after recalculation is run.
Service contracts are always Private.
User provisioning requests are always Private.
The ability to view or edit a document, report, or dashboard is based on a user’s access to the folder in which it’s stored.
Users can view forecasts only of users and territories below them in the forecast hierarchy, unless forecast sharing is enabled.
If the default access for Account is set to Private, the default access for Opportunity and Case must be set to Private as well. The default access for Contact must be set to Private or Controlled by Parent

External Organization-Wide Defaults

Guest users aren’t considered external users. Guest users’ org-wide defaults are set to Private for all objects, and this access level can’t be changed.
Chatter external users have access to only the User object.
When you first enable external organization-wide defaults, the default internal access and default external access are set to the original default access level. For example, if your organization-wide default for contacts is Private, the default internal access and default external access are Private as well. To secure access to your objects, we recommend that you set your external organization-wide defaults to Private.
After you enable external organization-wide defaults, the external access levels for User and newly created custom objects are set to Private by default. 5.

External users include

Customer Portal users
Authenticated website users
Chatter external users
Site users
High-volume Experience Cloud site users
Service Cloud Portal users

Organization-Wide Default Access Settings

Public Read/Write/Transfer - All users can view, edit, transfer, and report on all records. Only available for cases or leads.
Public Full Access - All users can view, edit, transfer, delete, and report on all records. Only available for campaigns. 3.

Controlling Access Using Hierarchies

If a master-detail relationship is broken by deleting the relationship, the former detail custom object’s default setting is automatically reverted to Public Read/Write and Grant Access Using Hierarchies is selected by default. 2.

Guidelines for Success with Roles

To prevent disruptions, avoid changing the role hierarchy during business hours.
If your organization uses Territory Management, forecasts are based on the territory hierarchy rather than the role hierarchy.
When an account owner isn’t assigned a role, the sharing access for related contacts is Read/Write, provided the organization-wide default for contacts isn’t Controlled by Parent. Sharing access on related opportunities and cases is No Access.
When you change a user’s role, the sharing rules for the new role are applied.
Don’t create individual roles for each title at your company. Instead, define a hierarchy of roles to control access of information entered by users in lower-level roles.
To avoid performance issues, we recommend that no single user owns more than 10,000 records of an object.
1. For users who must own more than that number of objects, don’t assign them a role or place them in a separate role at the top of the hierarchy. It’s also important to keep that user out of public groups potentially used as the source for sharing rules.
To improve performance, minimize the number of levels in your role hierarchy. Eliminate roles that aren’t needed, and delete sharing rules that grant access to records already shared via the role hierarchy.

Designing Record Access for Enterprise Scale

when an administrator moves a user from one branch of the hierarchy to another, Salesforce performs all of the following actions to ensure that other users have correct access to data owned by that relocated user.

Ownership Data Skew

When a single user owns more than 10,000 records of an object, we call that condition ownership data skew.
One of the common patterns involves customers concentrating ownership of data so that a single user or queue, or all the members of a single role or public group, owns most or all of the records for a particular object.

Ownership Data Skew - Solutions

Place them in a separate role at the top of the hierarchy
Not move them out of that top-level role
Keep them out of public groups that could be used as the source for sharing rules

Role Fields

The visibility of fields depends on your organization’s permissions and sharing settings.

Case Access - Specifies whether users can access other users’ cases that are associated with accounts the users own. This field isn’t visible if your organization’s sharing model for cases is Public Read/Write.
Contact Access - Specifies whether users can access other users’ contacts that are associated with accounts the users own. This field isn’t visible if your organization’s sharing model for contacts is Public Read/Write or Controlled by Parent.
Opportunity Access - Specifies whether users can access other users’ opportunities that are associated with accounts the users own. This field isn’t visible if your organization’s sharing model for opportunities is Public Read/Write.

For each role in your hierarchy, Salesforce automatically creates sharing groups, which you can use in sharing rules and manual sharing:
If territory management is enabled for your organization, each territory has sharing groups:

Asynchronous Parallel Recalculation of Org-Wide Defaults

When you update an org-wide default, recalculation is now processed asynchronously and in parallel
When deleting a group, the shares to the group become obsolete. Obsolete shares are deleted asynchronously during off-peak hours to minimize your waiting time during this operation.

Performing a large number of configuration changes can lead to very long sharing rule evaluations or timeouts. To avoid these issues, an administrator can suspend these calculations and resume calculations during an organization’s maintenance period.

Deferring sharing calculation is ideal if you make a large number of changes to roles, territories, groups, users, portal account ownership, or public groups participating in sharing rules, and want to suspend the automatic sharing calculation to a later time.

Without object-specific share locks, you can’t submit simultaneous sharing changes until recalculation across all objects is complete. If you’re enabling object-specific share locks, consider the following changes in your org.

When recalculation for an owner-based sharing rule is in progress, you can’t create, edit, or delete owner-based sharing rules for that object targeting the same group of users.
When recalculation for a criteria-based sharing rule is in progress, you can’t edit or delete that rule. But you can create, edit, or delete any other criteria-based or owner-based sharing rule for that object regardless of the target group of users.
Sharing rules can affect accounts and the associated account children—cases, contacts, and opportunities—so they’re locked together to ensure that recalculation runs properly.
Sharing rules can affect accounts and the associated account children—cases, contacts, and opportunities—so they’re locked together to ensure that recalculation runs properly. For example, creating or editing an account sharing rule prevents you from creating or editing a case, contact, or opportunity sharing rule. Similarly, creating or editing an opportunity sharing rule prevents you from creating or editing a case, contact, or account sharing rule before recalculation is complete. Locks aren’t shared across objects, except across accounts and associated account children.
You can’t modify the org-wide defaults when a sharing rule recalculation for any object is in progress. Similarly, you can’t modify sharing rules when recalculation for an org-wide default update is in progress.

Built-in sharing behaviors apply only to standard relationships.

Salesforce provides implicit sharing between accounts and child records (opportunities, cases, and contacts), and for various groups of site and portal users.
Sharing between accounts and child records
1. Access to a parent account—If you have access to an account’s child record, you have implicit Read Only access to that account.
2. Access to child records—If you have access to a parent account, you have access to the associated child records. The account owner’s role determines the level of access to child records.
Sharing behavior for site or portal users
1. Account and contact access—An account’s portal or site user has Read Only access to the parent account and to all of the account’s contacts.
2. Management access to data owned by Service Cloud portal users—Since Service Cloud portal users don’t have roles, portal account owners can’t access their data via the role hierarchy. To grant them access to this data, you can add account owners to the portal’s share group where the Service Cloud portal users are working. This step provides access to all data owned by Service Cloud portal users in that portal.
3. Case access—If a portal or site user is a contact on a case, then the user has Read and Write access on the case.
Group membership operations and sharing recalculation

Managing Folders

A folder is a place where you can store reports, dashboards, documents, or email templates. Folders can be public, hidden, or shared, and can be set to read-only or read/write. You control who has access to its contents based on roles, permissions, public groups, and license types. You can make a folder available to your entire organization, or make it private so that only the owner has access.

You can modify the contents of a folder only if the folder access level is set to read/write. Only users with the “Manage Public Documents” or “Manage Public Templates” permission can delete or change a read-only folder.

Best Practices

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
Groups can be nested (Group A nested into Group B), however don’t nest more than five levels. Nesting has an impact on group maintenance and performance due to group membership calculation. As a best practice, keep the total number of public groups for an organization to 100,000.
As a best practice, keep the number of ownership-based sharing rules per object to 1,000.
As a best practice, keep the number of criteria-sharing rules per object to 50; however, this can be increased by Salesforce
As a best practice, keep the territory hierarchy to no more than 10 levels of branches in the hierarchy.
The rule of thumb is to make your role hierarchy your non-sales hierarchy, try to flatten the sale department branch(es), and then use the territory hierarchy as your “sales” hierarchy. We do not recommend making the role hierarchy and territory hierarchy identical because it will cause unnecessary sharing activity.

To provide data access to peers who hold the same role/territory
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.

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
Only manual share records can be created on standard objects. Manual share records are defined as share records with the row cause set to manual share.
All share records (standard and custom objects) with a row cause set to manual share can be edited and deleted by the Share button on the object’s page layout, even if the share record was created programmatically

Teams

A team is a group of users that work together on an account, sales opportunity, or case.

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. You can’t create custom fields, validations rules, or triggers for teams.

Territory Hierarchy

Territories exist only on Account, Opportunity and master/detail children of Accounts and Opportunities
If the assignment rules for a territory are changed, sharing rules using that territory as the source will be recalculated. Likewise, if the membership of a territory changes, any ownership-based sharing rules that use the territory as the source will be recalculated.

Implicit sharing is automatic. You can neither turn it off, nor turn it on—it is native to the application. In other words, this isn’t a configurable setting; however, it’s very important for any architect to understand. 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.

Salesforce Classic vs. Salesforce Shield Platform Encryption: Which One Should You Use?

Salesforce Classic Encryption

Provides masking capabilites
Can be used to encrypt custom fields with 128-bit Advanced Encryption Standard (AES)
1. Subsequently, if users are assigned the correct permission set, they will only be able to see the encrypted data.
Is included in Base License cost of Salesforce.
1. Can only encrypt custom fields
Is excellent for masking sensitive data, such as credit card or SSN fields.
Limits custom field encryption to 175 characters
Needs profiles and permission sets to be configured for Salesforce users
Cannot be used in workflows or formula fields
If the system admin who is performing the weekly export has the “View Encrypted Data” permission, then the encrypted field will be backed up in its decrypted format. If that user does not have the correct permission, the backups will be shown in the masked format, so that user will be pulling random data rather than the actual data.

Salesforce Shield Platform Encryption

Salesforce Shield Platform Encryption protects Salesforce data at rest using either a generated or an uploaded encryption key.
Customers can manage their own encryption keys
Provides 256-bit encryption with a broader range of core Salesforce functionality, including search, lookups, validation rules, and Chatter. No masking is applied to Shield encrypted fields, so visibility needs to be controlled with field-level security.
The ability to encrypt standard fields, custom fields, files, and attachments
Can be used in workflows and formula fields.
it is recommended that you back up your tenant secret key. In the case that you accidently destroy a tenant secret, Salesforce is unable to retrieve it for you and you will lose all access to data encrypted with that key.

Managing Group Membership Locks

Salesforce uses a central Group object to manage visibility related to the Role Hierarchy, Territory Hierarchy, Public Groups and Queues. When administrative changes occur in these areas a group membership lock is taken to ensure data integrity is maintained while complex sharing calculations are completed

Role creation
Role deletion
Moving a role in the hierarchy
Adding a user to a territory
Removing a user from a territory
Moving a territory in the hierarchy
Territory deletion
Territory creation
Provisioning an internal user with an existing role
User role change
Provisioning a non-HVPU portal user under an account
Portal Account owner change
User Role change of a user who owns one or more portal accounts

In most cases, the Salesforce platform will try to obtain a lock for 10 seconds before failing. When one of the above operations holds a lock for more than 10 seconds or the load is heavy enough to cause a queue of operations that exceed 10 seconds, an exception may be thrown by another operation trying to obtain the lock.

Is the first member in his or her new role to own any data, Salesforce adds or removes access to the user’s data for people who are above the user’s new or old role in the hierarchy.
If the assigned new role has different settings for accessing contacts, cases, and opportunities, Salesforce does the following to reflect the change in settings.
1. Adds shares to those child objects where the new settings are more permissive
2. Removes existing shares where the new settings are more restrictive
If the user owns any accounts that have been enabled for either the Customer or Partner portals, Salesforce removes any child portal roles from the user’s original role and adds them as children to the user’s new role.
1. Salesforce also adjusts boss-implicit shares, which provide access in the hierarchy to records owned by or shared to portal users
2. Salesforce must perform these tasks for every portal-enabled account the user owns.

Moving a role to another branch in the hierarchy

One benefit to moving a whole role is that any portal accounts simply move along with their parent role, and Salesforce doesn’t have to change the related sharing. On the other hand, Salesforce must do all of the work involved in moving a single user for all users in the role being moved and for all of those users’ data.

Changing the owner of a portal account

The effort required for what looks like a simple data update—changing the name of the user in the Account Owner field—can be surprising. When the old and new owners are in different roles, Salesforce is not only moving the portal roles to a new parent role but also adjusting the sharing for all the data associated with the portal account.

Deferred sharing maintenance does not defer the recalculation of implicit sharing. The cascading effects to implicit shares continue to be processed immediately when sharing rules are changed by administrators or through the code.

There are two main criteria for determining whether deferred sharing maintenance is the right tool for your organization: the size and complexity of your realignment activities, and the flexibility you have to arrange a maintenance window with your customers.

Common Knowledge

The default number of roles used in an org’s portals or communities is 50,000. This limit includes roles associated with all of the organization’s customer portals, partner portals, or communities
Users with View All Data permission can view and preview files that they don’t own. However, if the file is in a private library, then only the file owner has access to it. 3.

Data’s Security with Shield Platform Encryption

When you encrypt a field, existing values aren’t encrypted immediately. Values are encrypted only after they’re touched or after they’re synchronized with the latest encryption policy
custom fields encryption
1. Email, Phone, Text, Text Area, Text Area (Long), Text Area (Rich), URL, Date, Date/Time
2. After a custom field is encrypted, you can’t change the field type. For custom phone and email fields, you also can’t change the field format
When you encrypt the Name field, enhanced lookups are automatically enabled. Enhanced lookups improve the user’s experience by searching only through records that have been looked up recently, and not all existing records.
Fields on external data objects, with data translation enabled, used in an account contact relations does not support encryptioon

Provide external access to records for communities

High volume communities
uses profile to access to group of users
one sharing set per object and per profile
Sharing sets can have two concepts
1. direct lookup on the records you want to share, e.g. accounts associated with cases
2. indirect lookup lookup on the records you want to share, account linked to asset associated with a case
supports
1. Account, Cases, Contact, Custom Objects, Service Contract, User, Work Order

Grants access to internal users access to records through sharing sets. A user in a share group gets full access to records owned by users associated with the sharing set.

Who are high volume portal users

Community Licenses

Customers
1. Customer community
  1. Interact with case, knowledge, event and calendar in read only mode
  2. Interact with the aforementioned plus, reports and dashboard, some sharing and events and calendar in read write.
2. customer community plus
  1. can have a delegated admin
Partners 1.

differences between Salesforce customer portal and Communities:

Portals provide external users the ability to access Salesforce whereas community clouds connect the internal users together in Salesforce
External users like partners or customers can communicate via Chatter in Communities. While on the other hand, portals don’t support Chatter
Communities are visually appealing and have easy to navigate user interfaces while portals’ user interface might look a little outdated
Portal is an extension of your CRM and users can access or view information limited to their account. Whereas, communities reside inside your organization and can be accessed globally.

Customer Community

large number of external users
access case/knowledge
access to 10 custom objects per license
No roles or advanced sharing
sharing sets
don’t own accounts
can be used with person accounts

Customer Community Plus

up to 2 million users
access to case/and or knowledge object
access to reports and dashboard
access to 10 custom objects
roles and advanced sharing (manual, apex and sharing rules)
sharing sets
can be used with person accounts

Partner Community

up to 2 million users
access to reports and dashboard
access to 10 custom objects
access to sales objects, Campaign , Lead and Opportunity
roles and advanced sharing (manual, apex and sharing rules)
sharing sets
can be used with person accounts

Enterprise Territory Management

better coverage of your organanization territories

Community Super User

Super user access allows partner users to view the data of other users with the same role in the partner role hierarchy. Super users can access data owned by other partner users who have the same role or a role below them. > Super user access applies to cases, leads, custom objects, and opportunities only.

The “Portal Super User” permission lets you do the following on your accounts:

View, edit, and transfer all cases
Create cases for contacts
View and edit all contacts, whether communities-related or not
View account details when they’re the contact on a case

Delegated Administration

The ability to assign limited admin privileges to users in your org who aren’t administrators.

Create and edit users in specified roles and all subordinate roles. User editing tasks include resetting passwords, setting quotas, creating default opportunity teams, and creating personal groups for those users.
Unlock users
Assign users to specified profiles.
Assign or remove permission sets for users in their delegated groups.
Create public groups and manage membership in specified public groups
Log in as a user who has granted login access to the administrator.
Manage custom objects and customize nearly every aspect of a custom object. However, a delegated admin can’t create or modify relationships on the object or set org-wide sharing defaults

Record-Level Locking

Updates to parent records and their children are being processed simultaneously in separate threads.
Updates to child records that have the same parent records are being processed simultaneously in separate threads.
Resources
Sharing Architecture