Salesforce Sharing Model

 Profiles and Permission sets are just a baseline for record access.

You can think of the model as an upside down triangle where the tools located at the top of the triangle provide 

the widest level of access to the greatest number of users, and tools that are located at the bottom can be used 

more precisely to grant certain kinds of access to the least number of users.

Starting at the top, there is territory hierarchy access, and this is part of a territory management feature that Salesforce provides.

Teams are groups of users that work together on objects like accounts, opportunities or cases.

Manual sharing allows users to intentionally grant record access to a user that would normally not have access.

Sharing rules, which can be used to extend access to users in public groups or roles.

Role hierarchy, which automatically grants access to certain users depending on where they fall on that hierarchy.

Org-wide defaults are used to restrict access.

Implicit sharing applies to records involved in parent-to-child relationships, and this can have big implications for your entire sharing model.

And sitting at the very bottom of all of this is that baseline access,and this involves a combination of a profile along with permission sets.

Implicit Sharing :

Happens when parent and children involved.

Overrides explicit sharing (Manual sharing & sharing rules).

Note :

Implicit sharing can occur when there are children records that are associated with a parent record.

For instance, accounts and contacts are designed with this kind of relationship. Contacts are considered children of a parent account, 

and what can seem reasonable is that users that could access a contact can also access the account. The very important thing to realize 

is that this type of relationship can override explicit sharing that is done with either manual sharing or sharing rules

View ALL or Modify All Permissions and View All Data or Modify All Data Permissions :

When granting access to an object, it is possible to use the View All or Modify All permissions. 

It is also possible to give you View all data or modify all data permissions to a particular profile. As you can probably guess, 

this will grant access to all records, and this is sometimes done for system administrators for good reasons, but realize 

that doing this will override whatever sharing model has been put in place, so it should be used with caution.

Access Grants :

Access Grants determine who sees what data in Salesforce.The process of determining this all starts with an object sharing table.

Object Sharing Table :

1.Object Sharing Tables Separate from the actual object table.

2.Object Sharing Tables Stores data about explicit and implicit grants.

Explicit Access Grant vs Implicit Access Grant :

Explicit :

1.Applies for territories and teams.

2.Happens when user creates record(owner).

3.When record is shared manually sharing/sharing rules.

Implicit :

1.Implicit sharing is built-in sharing that Salesforce offers.

2.Applies to Parent/child relationships.

3.can go both ways for parent and child.

Note : Access grants live in sharing objects.

Record access happens through access grants, and these grants reside in a sharing object or table, as you might think of it. 

Keep in mind that sharing objects are completely separate from the record object where the actual data being shared lived

Sharing Table Names :

Object sharing tables are created automatically and follow a very specific naming pattern.

For example, when the object record table is named Account, the sharing table will be named AccountShare, and the thing that ties these two tables together is the owner of the record.

Account --> AccountShare

And when dealing with a custom object, such as the one that is named MyCustomObject, the sharing table will be named MyCustomObject, followed by two underscores, and the word Share.

MyCustomObject --> MyCustomObject__Share

Record Access Calculation :

1.Only happens during a configuration change.

2.Improves record access performance.

3.Results in creation of access grants.

Salesforce uses Access Grants in order to identify how much access user have to object records. 

This comes into picture only when OWD for object is either PRIVATE or PUBLIC READ ONLY.

Access Grant also specify the sharing tool (like sharing rule, teams,roles etc) responsible for providing record access to user.

There are four types of access grants used by Salesforce:

Explicit grants can occur as a result of a few different things, but they always happen when a user creates a new record and thus becomes the owner. 

Implicit grants happen automatically whenever there's a parent-to-child relationship involved. 

Group membership grants occur whenever a user is a member of a group that has explicit access to a record. 

Inherited Grants are inherited when a user inherits access to a role, territory or group hierarchy.

Sharing Recalculation :

Sharing Recalculation happens when changes made to :

1.Group membership

2.Role hierarchies

3.Territory hierarchies

Sharing recalculation happens when changes are made to group membership or role hierarchies or territory hierarchies, 

and these changes could involve things like adding or removing members or changing where a member is placed in that hierarchy.

Sharing Recalculation can also be done manually.

The recalculation process can also happen when an admin manually kicks it off in setup.

Organization-wide Defaults :

1.Default level of access to user-owned records.

2.Used to initially lock down data for objects.

3.Set different levels for internal/external users.

4.Mixes with sharing tools to open up access.

Note :  org-wide defaults is the only way to limit record access.

The org-wide default can lock down access and then the other sharing tools can be used to open that access up to certain users or a group of users,

 and all of this is based on the concept of record ownership.

 

All records in Salesforce must be owned by an individual user or a group of users that are assigned to a queue.

OWD Default Levels :

1.Private

The most restrictive one is private, and this means that only the record owner and users that are above them in the role hierarchy can view or edit 

those records.

2.Public read-only

Public read-only allows all users to view records, but they can't edit them.

3.public read/write

public read/write is the least restrictive access, and this means that full access is allowed for all users.

4.public read/write/transfer (only for cases and Leads)

which is used only for case and lead records since these types of records can be transferred to another owner.

5.Controlled by parent

Controlled by parent applies to records that are part of a parent-to-child relationship, and this means that the child inherits the access of the parent.

6.Public Full Access (only for Campaign)

This one only applies to campaign records.

Implicit Sharing :

Implicit sharing is automatic and built into the platform and it takes precedent before any org-wide defaults are set. 

It all centers around the parent-to-child relationship, and it applies specifically to the account object when the account object is 

associated with a child object,such as contact.

Salesforce will automatically ensure that any users that can see that contact can also see the account that it is related to and they will in effect 

have read-only access to the account object as long as they are also able to see the contact.

And this level of access happens as a result of implicit sharing as it's built in automatically to Salesforce.

Record Access Logic :

How record access logic works in Salesforce?

It all begins with a Salesforce user, and every time that user attempts to access a record from a particular object and the org-wide default 

for that object is set as private or read-only, the system will look at the object's sharing table for all access grants. But that is not all. 

The system will also join the group membership table based on the ID of the user that's trying to access that object's record. 

And depending on what is found, the least restrictive access will be granted to that user, and this determines what kind of access they get.

Control by parent:

Control by parent means that users have the same access to the child object as they do to their parent, 

but it is important to understand that the control by parent setting is not the same thing as implicit sharing.

Change Org-wide Default (OWD) :

The original values would display until the operation completes because it's an asynchronous process that's happening in the background.

Notes :

1.Organization-wide settings are the only way to limit user record access.

2.Implicit sharing applies to parent-child relationships.

3.Settings checked every time user accesses record when set to private or read-only.

4.Private is most restrictive level of access.

Role Hierarchy :

1.Role hierarchies provide data access for a group of users. 

2.For the most part, it allows managers access to records that are owned by their employees. 

3.Essentially, record access is opened up vertically to users that are higher up in the hierarchy. 

4.By default, peers, or other members that are assigned to the role, will not have access to these records.

Note :

The role hierarchy sits right here in the middle. This means that baseline access, 

implicit sharing or org-wide defaults will override any access that is provided by the role hierarchy.

Remember, changes to a role hierarchy can result in a sharing recalculation, and depending on the size of the org, 

well this could have huge performance impacts.

Orgs that were created prior to the spring '21 release are limited to 500 roles, and orgs created after this time can create up to 5000 roles.

Implicit Sharing :

if a Salesforce user is able to access a contact, then they automatically have access to the parent account record, but that access is read-only.

objects are associated with separate sharing objects or tables, and each record in these sharing tables has a row cause. 

Sharing Row Cause :

1.Owner

Owner means the user accessing the record is the owner of that record.

2.Manual/Rule

Manual or rule indicates that the record was shared manually using the user interface or using an automated sharing rule.

3.Implicit Parent

Implicit parent means that if a user can access a contact, opportunity or case, then they automatically get read-only access to the parent account.

4.Implicit Child

An implicit child allows the account owner access to child records.

Implicit Sharing Types :

1.Parent 

1.Read-only access on parent account for user with access to the child record.

2.Does not apply when child set as "Controlled by Parent".

2.Child 

1.Access to child records for the owner of the parent account.

2.Does not apply when child set as "Controlled by Parent".

Notes :

The role hierarchy open up access to records vertically.

Implicit sharing can go both ways and is not same as "Controlled by parent" setting.

Sharing Rules :

1.OWD must be read-only or private.

2.Opens up object access for a group of users.

3.Specify the level of access in the rule.

4.sharing is based on :

   -> who owns the record

   -> values of certain fields

Note :

Sharing rules are created for objects, but you only do this if the org‑wide default for that object is set to private or read-only;

otherwise, there is no need to create a sharing rule since everyone has access to that object.

Public Group vs Queue :

Public Group :

1.Contains group of users.

2.Can include users in role or territory.

3.Used with sharing rules.

Queue :

1.Manage ownership of objects, such as leads, cases, and even custom objects.

2.The record is owned by the queue and not any of the users that are assigned to that queue.

3.Queues are not used in sharing rules.

owner-based sharing rules and criteria-basedsharing rule :

owner-based sharing rules starts with a Salesforce record that can be shared with a public group or a specific role, along with users assigned to roles above or below that role.

criteria-based role is the second type of sharing role that you can create. It works by looking at the value of one of our fields, and depending on what value is entered, sharing the object with a public group or role.

Note :

Territories can be included in a public group.

Public Groups :

When creating a public group, you will see a checkbox next to Grant access using hierarchies. 

Remember that from the role hierarchy. When this is checked, the sharing rule will be inherited by any members 

that also belong to a role higher in the role hierarchy. This setting is checked or enabled by default.

 

Manual Sharing :

First of all, if you are following along, you may need to enable manual user record sharing. It is not enabled by default in developer orgs.

In terms of who can grant access through manual sharing, that includes the record owner, 

obviously, but also any users that are above them in the role hierarchy, along with any user that has been granted full access to the object,

and finally, any administrators.