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

Salesforce Composite resources/Composite API

 REST API composite resources are helpful to improve application's 

performance by minimizing the number of round-trips between the client and server.

what is Composite resources ?

Composite resources is an enhanced form of rest api which executes a series of rest api

requests in a single call.

It helps you to do multiple operations like read, create, update and delete salesforce data in single callout.

Note :

you can use output of one request as the input to a subsequent request response bodies and status of all these rest api 

requests are together returned in a single response body.

All the series of rest apis are counted as a single call towards your API limits.This is executed in the context of the same user.

1.Series of REST API requests in a single call.

2.Multiple CRUD Operations.

3.Output of one request as the input to a subsequent request.

4.Response bodies and status in a single response body.

5.Counts as a single call towards your API limits.

6.Executed in context of the same user.

Composite Resources consists of 

1.URI : /vxx.x/composite

2.Formats - JSON

3.HTTP method- GET,POST

4.Authorization : Bearer token

5.Composite Request Body

6.Composite Response Body

Composite request body :

{

   "allOrNone" : true,

   "collateSubrequests": true,

   "compositeRequest" : [

     { Composite Subrequest},

     { Composite Subrequest},

     { Composite Subrequest}

   ]

}

Composite request response :

{

   "compositeResponse" : [

      {  Composite Subrequest Result },

      {  Composite Subrequest Result },

      {  Composite Subrequest Result }

   ]

}

Why Composite Resources

Lets understand the advantage of composite API.

1.Multiple REST API calls for single call

2.Processing speed can be made faster by collating the subrequests.

3.Improves the performance of the application

4.No additional coding required at Salesforce. 

5.Single call toward API limits.

6.Synchronous responses.

7.Multiple ways in composite resources work.

8.Upsert upto five levels deep relationships.

9.Flexible on upserting related or non related records.

10.Can do a GET subrequest and the result can be input to next POST subrequest.

11.Can handle more complicated and related objects and data. 

Types of Composite Resources :

1.Composite API

2.Batch

3.SObject Tree

4.SObject Collection

5.Grapths