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. 

Organization-wide Defaults (OWD)

 Organization-wide Defaults are used to lock down data records for specific objects.

Each object will be assigned a level and these can be different for an internal versus external users.

Access will then be opened up to other users or groups using a mixture of manual sharing. sharing roles, and the role hierarchy.

Access Levels :

1.Private 

Private is the most restrictive level of access and this means that only the record owner and any users above them in the role hierarchy 

can view, edit, or report on those records. In other words, only managers can see the records of their employees. 

2.Public read-only

Public read only indicates that all users can view and report on records, but only the owner and their managers can actually edit the record, 

and remember all this is still dependent on whether users have the appropriate object level permission.

3.Public read/write

Public read/write access means that all users can view, edit, and report on all records. 

So this is kind of the least restrictive level of access and this one should only be assigned after really careful consideration.

4.Public read/write/transfer

Public read/write/transfer is a special level that is only available to lead and case objects and since those are the only kinds of 

accounts that allow for a transfer to happen.

Grant Access Using Hierarchies

By default, the Grant Access Using Hierarchies option is enabled for all objects, and it can only be changed for custom objects.

This is checked for all objects by default, but important thing to remember, admins can uncheck this box for custom objects only.

Note :

org-wide defaults are the only way that you have to limit record access for users.

Access Grants :

Access grants start with the org-wide default level for each object.

And when they are set to private or read only, an access grant is assigned, and this determines how much access a user or group has to that object's records. 

And that leads us to what those access grant types can be.

Note : Access grants determines how records can be accessed.

1.Explicit grants

Explicit grants happen when a user becomes the owner of a record or a user 

shares a record using one of the sharing tools that I already mentioned.

 

2.Group Membership grants

Group membership grants occur when an explicit grant is directly assigned to a member of a group, queue, role, or a territory.

3.Inherited grants

Inherited grants happen when a user inherits access because they are part of some group or hierarchy. 

This comes into picture when user get access to records because of role hierarchy, territory hierarchy or inherit access through group hierarchy.

4.Implicit Grants

Think of this as Salesforce's built-in sharing. It just applies to objects that have a parent-to-child relationship. 

Sharing database Architecture :

Salesforce store access grants in three types of tables:

1.Object Record Tables

This table indicate which user, group or queue own each record.

2.Object Sharing Tables

This table store information like which record is shared with which user or group either by apex manage sharing rule 

or declarative sharing when object OWD is not PUBLIC READ/WRITE.

This table store data that supports explicit and implicit grants.

3.Group Maintenance Tables

This table store data that supports group membership grants and inherited grants. 

Role Hierarchy :

Represents group of managed users.

Managers have same access as employees.

Peers do not share access to records.

Note : Poorly designed role hierarchies can have big impact on org maintenance and performance.

Salesforce Permission Set Groups

 Permission Set Group - The Next Generation Permission Management.

The permission set group, are a bundle of permission sets.

You can group permission sets based on user roles using Permission Set Groups for easier user permission management.

Move the bulk of the permissions from the profiles into smaller chunks and break it into multiple permission sets. 

This way each permission set is granular and does not have overlapping functionality.

The Permission set group allows to combine multiple permission sets into a single permission set group for user assignment. 

Use a Permission set group to multiple permission sets together based on the job role. 

You can include a permission set in more than one permission set group. You can also remove individual permissions from a group with the muting feature.

Note : 

1.whenever possible permissions should be handled by permission sets and permission set groups and not profiles.

2.Permissions moving from profiles to permission sets or permission set groups.

Salesforce IP Ranges

 we can define two types of IP Ranges in salesforce.

1.Login IP Ranges

2.Trusted IP Ranges

Want to improve user security for your organization beyond usernames and passwords? 

Use login IP ranges and trusted IP ranges to control the IP address ranges from which your users can log in to Salesforce.

Login IP ranges control login access for a user profile. Users with profile login IPs can only log in from IP addresses within the range; 

otherwise, they’re denied access to Salesforce. Login IP ranges are typically used to restrict login IPs at a granular level.

Trusted IP ranges control login access for an organization. When users log in from trusted IPs, they aren’t challenged to verify their identity 

(such as by entering a code sent to their mobile phone). Unknown users logging in from non-trusted IPs are challenged to verify their identity, 

and if successful, allowed to access Salesforce. Trusted IP ranges are typically used to “allowlist” IPs at the organization level.

Trusted IP Ranges :

1.Trusted IP Ranges Set at org level.

2.Computer activation not required.

 User logging in within the Trusted IP range means that computer activation is not trusted.

 so effectively, one particular login restriction is removed.

 

 Note : Trusted IP ranges remove the computer activation requirement.

Login IP Ranges :

1.Login IP Ranges set at Profile or user level.

2. Prevents login outside range.

Login IP ranges prevents user login outside the range.

Note :

Even if user IP address is in the range of Trusted IP Ranges but not in Login IP Ranges,

user still will not able to login and get the same error message.

Login Hours :

Login Hours settings will control what hours the user can log in during.

1.The first thing that is checked on any login is your profile login hours. 

If you have login hours on your profile, and you are outside login hours, 

the login process stops and you are denied access. No further checks are done. 

If you don't have login hours set, or if you are within login hours, you move to step 2.

2.Next we look to see if your profile has an IP restriction set on it. If you do and you are not within the login IP range, 

you are denied access. No further checks are done. No verification email. Nothing. Your access is blocked absolutely. 

If you are within your profile IP range, you are granted access.

3.If there is no profile IP range, then we will look for a browser cookie set that identifies that this user has accessed this org previously, 

or if they are within the organization-wide IP restrictions (Setup>Security Controls>Network Access). 

If you are your browser does not have the cookie, or is you are not within the org-wide range, your access is blocked but there are two ways to still gain access.

Salesforce Functions

 what is a function?

A single purpose,on demand,short-lived microservice without complex infrastructure.

1.Elastic Scale

Extend Salesforce data with elastic compute that scales on demand.

2.Stay on platform

Build with pre-configured secure access to C360 data.

3.Expand Talent Pool

Extend Salesforce data with elastic Build inclusive with all your developer talent 

using open languages and tools that scale on demand.

Anatomy of a Function :

Each javascript Function exports an async function this is where all of the works is done.

module exports = async function(event,context,logger){

  // Do something

}

Each function has access to the event,context & logger objects.

The event contains the payload that was passed into the function.

The Context allows access to an authenticated Org and the Salesforce SDK.

The logger helps you log right from your function.

Invoking Function(Sync)

Functions can be invoked directly from Apex.

you can use the functions.Function class to get a function reference 

and invoke it by passing it a JSON payload.

You can then get the response from the functions.FunctionInvocation object.

You can invoke them synchronously and asynchronously

public with sharing class GenericFunctionInvoker{

 public static String invoke(String functionName,String payload){

  functions.Function function=functions.Function.get(functionName);

  functions.FunctionInvocation invocation=function.invoke(payload);

  String response=invocation.getResponse();

  return response;

  

 }

}

Invoking Functions (Async) :

An async invocation receives a callback, which inherits from functions.FunctionCallback.

public with sharing class GenericFunctionInvoker{

 public static String invoke(String functionName,String payload){

  functions.Function function=functions.Function.get(functionName);

  functions.FunctionInvocation invocation=function.invoke(payload, new MyCallback());

  

 }

 public class MyCallback implements function.FunctionCallback{

 

 public void handleResponse(functions.FunctionInvocation invocation){

   String response=invocation.getResponse();

 }

 

 }

}

Enable Functions in scratch org :

Edit the config/project-scratch-def.json file to enable the "Functions" feature and save. We will use this configuration to create a new Scratch Org:

{

  "orgName": "acme company",

  "edition": "Developer",

  "features": ["Functions"]

}

Salesforce Sharing Model

 Open Access to Records

1. OWD 

Restrict Access 

1.Private

2.Public R/O

3.Public R/W

2.Role Hierarchy 

Open up Access Vertically

3.Sharing Rules 

Open up Access Horizontally

4.Manual & Apex Sharing 

Open up Access Flexibly

Steps to architect Sharing :

Define actors,permissions and access level.

1.Who are the actors ?

Actors are the types of users in the application.

Defining actors allows you to select licensing and high level profiles.

--> Licensing

--> Profiles

2.What can they do ?

--> Profile/Permission Set CRUD 

--> Field Level Security

what can actors do 

What objects can they Create,Read,Update or Delete ?

To what fields do they have visibility?

3.What data can they see?

--> OWD

--> Ownership and Queues

--> Role Hierarchy

--> Public Groups

--> Sharing Rules

--> Programmatic Sharing

what data can the actors see

Identify the most restrictive visibility for each object.

--> Define org-wide defaults

--> Private objects visible to record owner.

Open up additional visibility with further capabilities.

1.Role Hierarchy

2.Public Groups

3.Sharing Rules

4.Teams

5.Manual Sharing

6.Implicit Sharing

7.Programmatic Sharing.

Implicit Sharing for Accounts :

1.Automatic and cannot be turned off.

2.Parent Implicit Sharing - Access to Parent (Account) records from children.

 Access to a parent accounts - If you have acccess to an account's child record,

 you have implicit Read-only Access to that account.

3.Child implicit sharing - Applies to contact,opportunity and Case objects(children of the account).

  Access to child sharing 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.

Implicit Sharing for Portal Users :

Account and cases access - An account's portal user has Read only access to the parent 

account and to all of the account's contacts.

Note : Operations such as changing a user's role can trigger a recalculation of sharing rules.

Community License Types :

1.Partner Community Licenses

2.Customer Community Plus Licenses

3.Customer Community Licenses

Experiences or Communities are branded spaces for customers,partners and employees to connect.

1.Commerce Portals (External Apps also previously called Lightning External Apps Starter)

Custom digital experiences to engage any external stakeholder, including brand engagement and customer loyalty. Limited access to CRM objects.

2.Customer Community

Business-to-consumer experiences with large numbers of external users who need access to the case object and/or Salesforce Knowledge.

3.Customer Community Plus

Business-to-consumer experiences with external users who need access to reports & dashboards and may need advanced sharing.

4.Partner Community

Business-to-business communities that need access to sales data such as partner relationship management.

5.External Apps (previously called Lightning External Apps Plus)

Highly customized experiences incorporating CRM objects, custom objects, external data, and extra storage. 

Ideal use cases are dealer, vendor, or supplier portals. Also commonly used for franchise management, marketplaces, and multi-level marketing.

6.Lightning Platform Starter/Plus

Extend the power of CRM to every business process, every app, and every employee to build engaging employee communities and concierge sites.

7.Purpose-built cross-product community licenses

These are the community licenses that allow external users to access other Salesforce products/functionality namely Tableau CRM 

and various Industry solutions.

Note :

Customer Community for Customer (Person Account/Contact). Task Object has Read only

Community Plus is for Customer (Person Account/Contact). Task has Read/Write

Partner Community is for Partner (Business).

Customer Community       – Business-to-consumer communities with large numbers of external users. Enable customer self-service, extend business processes, and build deeper customer relationships.

Customer Community Plus  – Business-to-business communities for support and non-sales scenarios, such as eCommerce.

Partner Community        – Business-to-business communities that need access to sales data such as partner relationship management. Increase sales through resellers, distributors, agencies, and brokers.

Enum valueOf() method - Winter'22

 The valueOf() enum method converts a specified string to an enum constant value.

An exception is thrown if the input string doesn’t match an enum value. In previous releases, using this method resulted in a runtime error.

ex :

public enum Season {WINTER, SPRING, SUMMER, FALL}

string currentSeasonInput = 'winter';

// With Winter'22

Season currentSeasonWithValueOf = Season.valueOf(currentSeasonInput);

System.debug('Current season (new technique): ' + currentSeasonWithValueOf); // result : Current season (new technique): WINTER

ex:

Before Winter’22, to get an Enum constant value from string, you had to iterate through all the values searching for a matching name.

    public enum Season {WINTER, SPRING, SUMMER, FALL}

      String currentSeasonInput = 'WINTER';

  

      // Before - searching the values()

        Map<String, Season> seasonsByName = new Map<String, Season>();

        for (Season enumValue : Season.values())

        {

            seasonsByName.put(enumValue.name().toUpperCase(), enumValue);

        }

        Season currentSeason = seasonsByName.get(currentSeasonInput);

        System.debug('Current season (older technique): ' + currentSeason);  // result : Current season (older technique): WINTER