Monday, 27 September 2021

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.



Monday, 13 September 2021

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