With queues and public groups,The GroupMember object stores members, but not for role-related groups.
The membership for these role-related groups is not visible to us.
These "group maintenance" records in conjunction with "sharing" records allow Salesforce to get results fast.
View Access to all records, regardless of sharing settings.
If a user has the system-level permission checked on their permission set or profile, they have view access to every single record in the system.
Object-level and field-level permissions still apply. But as long as a user with this permission has read access to an object, they would get to view all records of that object.
Edit access to all records,regardless of sharing settings.
It gives edit access to every record in the system as long as the write‑object level and field‑level permissions are present.
View access to all records for the given object.
The View All permission, unlike the View All Data permission, is defined for each object.
If I have View All permission on the Account object along with read access to the object,
it means I will be able to read all account records regardless of other sharing settings.
Edit access to all records for given object.
Modify All is an object-level permission that gives edit access to all records of an object.
If a user has this permission to the account object along with read and edit object-level permissions,
they would be able to view and edit all account records.
of sharing and visibility any time someone requests records from the database.
The sharing architecture for orgs with large data volumes should consider the impact of recalculations.
When designing a sharing model for orgs with large data volumes, it is very important to keep in mind what impact recalculations can have.
1.Adding, removing or editing a sharing rule.
This recalculation, like most recalculations, is run asynchronously and can be seen on the Background Jobs page and set up, and you receive an email once the recalculation is complete.
The more records impacted by the sharing rule, the longer the calculation.
There is an exception to this rule, when the number of impacted records from an ownership-based sharing rule insert or update is less than 25,000.
In this case, the job is run synchronously, it is not available on the Background Jobs page, and you won't receive an email when it's done.
Note : Synchronous,no email,and not visible under background jobs.
2.While this recalculation is in progress, you cannot change the OWD or make changes to sharing rules for the object being processed.
Note : No changes to OWD or sharing rules on object while recalculation is in progress.
You can still make changes to sharing settings on other objects.
Changing organization-wide defaults on an object can also result in a long-running recalculation.
-> Changing to a more permissive OWD means removing sharing records.
If you change the organization-wide default from save private to a more permissive setting, some sharing records may no longer be necessary.
That is when Salesforce runs jobs to clean up access.
-> Changing to a more restrictive OWD means creating sharing records.
If you change the organization‑wide defaults to a more restrictive setting, for example from public read/write to private,
Salesforce may now need to include sharing rules that previously did not exist.
-> Sharing rules can exist on objects with a Public Read/Write OWD.
Remember that if your object has a public read/write OWD, it can still have sharing rules defined on it.
That's a good thing because if you change your object's OWD setting to public read/write, you don't want your sharing rules to just disappear.
-> Need recalculation when OWD is set to less permissive.
This does mean that when you switch to a more restrictive setting, these rules would need to be recalculated.
-> changing a user's role resulted in a sharing recalculation.
changing the user's role resulted in a change to a role group that was used as a source for a sharing rule.
Note : A role group that changed was used as a source group for an ownership-based sharing rule.
Changes to membership in groups that are used as a source for ownership-based sharing tools can result in long-running recalculations
Examples of actions that can impact group membership is changing user roles,changes to queues and public groups, changes to the role hierarchy itself, and changes to territories.
Implicit access through role settings is tracked in sharing objects.
Every role has settings for implicit access to contacts, opportunities, and cases.
Access given through a role hierarchy is not tracked in sharing objects, but access given through these
implicit settings is tracked in the sharing object and needs to be recalculated if the role settings change or if a user's role changes.
Group Membership Calculations:
==============================
The GroupMember object, which contains data on which users are part of which groups.
-> Membership for queues and public groups is visible and editable.
For queues and public groups, we can see group members in this object and even insert records to change group membership.
-> Membership for other system-managed groups is not visible to us.
But for hierarchy groups, membership data is not visible in the GroupMember object and is managed internally by Salesforce.
Note : The Two kinds of groups that Salesforce created for every role, the Role group and the RoleAndSubordinates group.
Territory Hierarchy :
Territory hierarchy also results in creation of two groups.
1. Territory group
-> All users in the territory
-> All users in a higher territory
2. Territory and subordinates group
-> All users in the territory
-> All users in a higher territory
-> All users in a lower territory
Group Membership Calculations :
Changes to any of the hierarchies, Salesforce needs to recalculate group membership.
Changing a user's role, for example, results in changes to group memberships for groups associated with roles above and below the user's old and new role.
Changing the hierarchy itself also results in changes to group members from multiple groups.
Mmembership recalculations can be costly too, especially if you are making changes to a large number of users, roles, or territories.
When recalculating group memberships, there can also be concerns around locking and timeouts.
Note :
Create more roles: In Salesforce orgs created in Spring ’21 or later, you can create up to 5,000 roles.
In existing orgs, the default limit hasn’t changed. You can create up to 500 roles and can contact Salesforce Customer Support to increase this limit.
group membership calculations cause :
Database Lock :
Databases allow operations to lock entire tables or some rows in the table. Until the operation completes,
all other operations that want to work with the locked data are forced to wait until the lock is released.
Databases do this for the same reason you might lock an entire document while working on it, to prevent
others from overwriting your work or to prevent others from reading a half-complete document.
Granular Locking :
-> Lock only a subset of records.
e.g. when modifying a role group, only lock rows related to groups being modified.
Salesforce uses granular locking when performing group membership calculations.
This means Salesforce locks only relevant group membership records instead of locking the whole group membership object.
-> Enables Parallel Processing
Group membership operations that modify unrelated groups can proceed in parallel without worrying about locks.
This means if two group membership operations are modifying unrelated groups, they can proceed in parallel because they need to lock different sets of rows.
Granular Locking Conflict :
-> Operations need to wait
Group membership operations ususally do not take a very long time and can wait on each other.
what if two group membership operations need to lock the same set of rows, for example operations that modify role groups that have a hierarchical relationship.
A group membership operation that needs to acquire a lock on rows locked by another group membership update can usually wait for the other operation to release the lock.
Note : These operations usually don't take too long.
-> Timeout when waiting
If an operation waits too long,Salesforce terminates it with an error saying it was unable to acquire a lock.
If the operation does take too long, you can see an error stating that Salesforce was unable to acquire a lock.
The probability of such loss increases when you are dealing with a large number of changes to users and groups at the same time.
Group Membership Update Considerations :
1.Ownership-based sharing rules
A group membership change causing a sharing recalculation can hold longer locks.
This is a case where a group membership operation can take a much longer time, preventing you from performing other group membership operations.
2.Schedule at different time
Running operations at different times, including apex tests,reduces locks.
You should also make an effort to schedule such operations at different times if possible to reduce the probability of locking errors.
A release that includes changes to group memberships or includes Apex tests that make changes to group memberships could be scheduled for a different time from a major role reassignment,
for example. Apex tests cannot make permanent changes to group membership, but they still lock group membership rows.
3.Build resilient operations
Automated operations should attempt to retry of there are failures due to locks.
Automated processes that make such changes to group membership should have resiliency built into them.
They should attempt to retry if such operations fail due to locking errors.
Defer Sharing Calculations :
1.suspend sharing calculations
2.Make changes without triggering calculations.
3.Resume calculations and run a full sharing recalculation.
4.Useful when performing multiple operations that can trigger calculations.
5.Not enabled by default.
You can suspend sharing calculations, make all the changes you want without triggering expensive recalculations, and then have Salesforce run a single full recalculation right after you resume.
This is a great option if you need to perform multiple operations that could result in expensive recalculations, like a number of sharing rules or major role realignments.
This feature isn't enabled by default. If you need this enabled in your org, you would need to reach out to Salesforce Support.
Note :
With Defer Sharing Calculation you can avoid this by suspending sharing rule calculations from evaluating immediately after you make sharing rule changes.
You can resume sharing rule calculations during maintenance windows to have minimal impact on users.
Defer Sharing Calculations :
1.Defer Sharing Rule Calculations
2.Defer Group Membership Calculations
"Manage Sharing Calculation Deferral" permission and "Manage Users" permission have to users.
In Setup, I can navigate to the Defer Sharing Calculations page to use these features. Even without this permission set,
I would have been able to navigate to this page, but the permission gives me access to suspend, resume, and recalculate.
Avoding Data Skew :
===================
1.Ownership Data Skew
Ownership data skew is when a single user or queue owns over 10,000 records of an object.
To avoid performance problems, distribute records so that no single user or queue owns over 10,000 records.
When Ownership Skew is unavoidable :
ex: A single user owned all records.
1.Ensure user has no role, or role stays at the top of the hierarchy.
2.Ensure user is not in any group used as a source for an ownership-based sharing rule.
2.Parent-child Data Skew
when you have over 10,000 child records associated with the same parent.
Let's take Accounts and Contacts as examples. Every time a user gains access to a contact, Salesforce implicitly gives that user access to the parent account.
And when a user loses access to a contact, Salesforce needs to, but it cannot immediately take away access to the account.
Salesforce needs to check every child record to ensure the user does not have access to them. Once confirmed, Salesforce can remove the implicit account access.
Another example of parent-child skew is when a user owns a skewed account, and their role settings give the user implicit access to all child contacts.
An example of what could go wrong in this scenario, if the user loses ownership of the skewed account, Salesforce would have to remove sharing for every child contact.
Resolving parent-child Skew :
1.Person Accounts
Person accounts are one option of course, but not everybody loves all the baggage that comes with person accounts.
2.1:1 Model
Another model is to just create an account for every contact using some automation, a 1:1 model just like person accounts, but maintained by you.
3.Household Model
Yet, another popular option is a household model where you group contacts under households.
This option can be attractive if the company's products or services are used by whole households.
Apex Managed Sharing :
=====================
Similar to manual sharing - grant access to individual records by inserting rows in sharing objects.
Insert a Share Record through Apex
ex :
Follower__Share objFollowerShare = new Follower__Share();
objFollowerShare.ParentId = 'a032x00000AViTgAAL';
objFollowerShare.UserOrGroupId = '0052x000002Yj03';
objFollowerShare.AccessLevel = 'Edit';
objFollowerShare.RowCause = 'Manual';
Database.SaveResult sr = Database.insert(objFollowerShare,false);
The code will work just fine, but having RowCause set to Manual can be a problem.
User Managed Sharing :
1.Sharing button can be added to page layouts.
2.Available to users with "full" record access.
-> Record Ownership
-> Users with a higher role
-> Users with Modify All or Modify All Data
3.Allows users to add,remove or update sharing records that have RowCause set to "Manual".
Implications of RowCause "Manual" :
1.Managed by users
Users can delete sharing records created through Apex or the Data Loader.
This means users can go and delete or modify these sharing records as long as the user has full access to the record.
2.Deleted if owner is changed
Salesforce removes all manual sharing from a record when the owner changes.
Note :
In User Managed Sharing is, a user who has full access on the record shares the records with others, but when the record owner is changed, this record will be removed from Sharing table.
Similarly, when apex sharing is defined as “Manual” on RowCause, it will remove record from sharing table when the record owner is changed.
Apex Managed Sharing :
1.Use a different value for RowCause.
-> Create an Apex sharing reason
-> Assign the new Apex sharing reason to RowCause instead of "Manual".
A sharing record inserted with an Apex sharing reason as the RowCause is visible to users with full access through the Sharing button,
but it is not managed by the user, which means the record owner will not be able to edit or delete it. Such a record will also persist through ownership changes,
which is the behavior we would want.
Note : Apex sharing reasons can currently only be created in Salesforce Classic.
why Recalculate Apex Managed Sharing ?
1.We deployed the trigger,but older records need sharing too.
2.Possibility of a bug in current trigger.
3.Changing OWD settings can require Apex sharing recalculation.
Manager Group Sharing :
======================
Manager groups allow users to share records with their direct management chain and direct subordinates.
Manager lookup on user Record :
Can be used to capture direct reporting relationships.
A user record in Salesforce has a standard Manager field, which is a lookup to user.
This field can be used to model direct reporting relationships not possible or feasible through the role hierarchy.
Groups based on direct managers :
Records can be shared with management chain or subordinates.
Salesforce uses this management hierarchy to build manager groups that records can be shared with.
These groups, as we're about to see, allow users to share records with people's managers or their subordinates.
These are relationships modeled through the Manager field on the user object.
Salesforce creates 2 groups for each user, a managers group and a subordinates group.
Managers and Subordinates Groups :
Manager Group :
Members include the user's manager, the manager's manager and so on.
Subordinates Group :
Members include the user, the user's direct reports and the user's indirect reports.
Enable Manager Groups :
As admin, you can enable Manager Groups from Setup | Security Controls | Sharing Settings, look for Organization-Wide Defaults and click Edit button,
scroll down to Other Settings and select Manager Groups and then click Save.
SELECT Id,DeveloperName,Type FROM Group
To run a SOQL query on the Group object to see the new groups that were created.
As you can see, there are ManagerUp and ManagerDown groups with user IDs appended to the group's name.
These are not very user‑friendly names and you don't see them on the user interface, but these are the names Salesforce uses internally.
Just like role groups, the members for these groups are not visible to us. They are managed internally.
If we ran a query on the GroupMember object, we would not see any members for these groups.
Once created, these groups are available for manual sharing.
We can even create sharing rules based on manager groups.
Limitations of manager groups:
1. we can only pick specific manager groups when creating sharing rules.
2. Apex sharing reasons not suppoeted.
Manager groups do not support Apex sharing reasons.
This means we would need to use RowCause Manual, and the records would be deleted on ownership change and can be managed by users.
3.Cannot be added to other groups.
Salesforce lets us add role groups and public groups into other public groups and into queues, but manager groups cannot be added into any other groups.
Summary :
-> Different ways record access is granted
1.Explict grants in sharing objects.
Explicit grants and sharing tables associated with objects and includes things like manual sharing and sharing rules.
Salesforce sometimes needs to recalculate these access grants.
2.Group Membership grants
Group membership grants where users obtain access to records by virtue of being in a group. For example, if an explicit grant gives a group access to a record, users part of their group gain access through this mechanism.
3.Inherited grants (Roles and terrirories)
Inherited grants where users gain access to records by virtue of being part of a role or territory hierarchy.
4.Implicit grants(built-in sharing)
Implicit grants, which supports implicit or built‑in sharing behavior, for example users obtaining access to parent accounts for cases or opportunities they can access.
-> Recalculation is sometimes necessary
Salesforce sometimes needs to recalculate sharing and group membership, and we discussed techniques for dealing with them,
including deferring calculations, avoiding data and ownership skews, scheduling changes at different times,
and designing a sharing model that reduces the need for expensive recalculations.
-> Apex Managed Sharing
Apex managed sharing, which is essentially just inserting records into sharing objects using Apex. We learned that using an Apex sharing reason as the RowCause ensures that Apex manages these sharing records instead of the user.
-> Manager group sharing
Manager groups, which allow sharing records with the user's management chain or subordinates.
Note : Based on manager lookup , not roles.
It's easy to confuse this with the role hierarchy because Salesforce often uses the word manager to refer to higher ups in the role hierarchy.
A key difference here is that manager groups are based on the manager listed on the manager lookup on the user record,
while the role hierarchy is based solely on how the role hierarchy is set up, regardless of direct reporting relationships.
