SALESFORCE LIMITATIONS AND BEST PRACTICES

 Sharing Rules :

The limit is across both Standard and Custom Objects as 300 Maximum rules with 50 Criteria Based rules on Enterprise and Unlimited/Performance Editions only.

You can create up to 50 criteria-based sharing rules per object.

Note :

On an object where the OWD setting is 'Controlled by Parent' you will not be able to set up sharing rules, so you need to change this, 

e.g. On Contact to either 'Private', 'Public Read only' or 'Public Read/Write' to add sharing rules on this specific object.

As a best practice, keep the number of ownership-based sharing rules to 100 per object, 

and keep the number of criteria-sharing rules to 50 per object.

Note : 

1.Removing an Account team member doesn't remove an Opportunity team member.

2.Know that platform out of the box 'implicit' sharing doesn't apply to Apex sharing.

3.You can create up to 10 Apex sharing reasons per custom object.

Not Possible with permission set :

The only things that must to be controlled by Profiles and can't be structured in Permission Sets are:

Page Layout Assignments

Desktop Client Access

Login IP Hours

Login IP Ranges

runAs method in Apex Test Classes

 1.RunAs will use the record sharing view-ability of a record when viewing. It doesn't respect user permissions or FLS.

2.You can only use RunAs in test methods, and it doesn't respect user license limits.

The runAs method ignores user license limits. You can create new users with runAs even if your organization has no additional user licenses.

3.RunAs can be used for mixed DML exceptions that would normally occur.

4.RunAs can take a package version as an argument.

ex :

      // Run test as managed package version 1.0

      System.runAs(new Version(1,0)){

          try{

              insert o;

          }

          catch(System.DMLException e){

              System.assert(false, e.getMessage());

          }

      }

Salesforce Implement Sharing and Data Skews

 

Implement sharing is defined and maintained by the system.

1.Parent 

2.child

3.Portal

4.Case

5.Share Groups (High Volume)

Parent Implicit Sharing :

'Parent implicit sharing' provide read-only access to parent records(Account only),

when user has access to children record,such as : Opportunities,Cases,or Contacts for that account.

This does not mean the user must be the record owned of the child ecord.

(or)

The Parent Implicit sharing provides read-only access to parent record if the user 

is having access to the child record.

Note :

Only affects Account to Case, Contact and Opportunity.

Account = private and Child !='Controlled by Parent'

As soon as a user has atleast Read access to a Case,Contact or Opportunity the user has Read access to the related Account.

Child Implicit Sharing :

Child Implicit Sharing is ability for Account owner to access child records (contacts, opportunities, and cases),even they are not owned by Account owner. 

The account owner's role determines the level of access to child records (read-only or read/write).

The child Implicit sharing provides Read/Write access to child record if the user is the owner of the parent record.

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

Not used when sharing on the child is 'Controlled by Parent'.

Controlled by child access settings for the account owner's role.

Supports account sharing rules that grant child record access.

Supports account team access based on team settings.

When a user loses access to the parent, Salesforce needs to remove all the implicit childern for that user.

Note :

Only affects Account to Case, Contact and Opportunity.

Only affects Account Owner.

Each role independently can define whar child-record access the Account Ownership provides. 

Portal Implicit Sharing :

Portal Implicit Sharing will provide Read-only access to portal account 

and all associated portal user's contact record using portal role sharing.

Access to portal account and all associated contacts for all portal users under that account.

Shared to the lowest role under the portal account.

High Volume Portal Implicit Sharing :

In this Implicit sharing any record owned by high volume portal users will be shared 

with other high volume users who are part of sharing set.

High Volume Parent Implicit Sharing :

In this implicit sharing, read only access will be given to parent account 

of records shared through a sharing set to other user members.

Controlled by Parent vs  Implicit Sharing :

Note : Controlled by Parent isn't the same as Implicit Sharing.

Implicit Sharing :

Implicit Sharing is when a user gains access to a child record and also gains read-only access to the parent.

e.g. a contact is assigned to a user, and thus gains read-only access to the account.

Implicit sharing only has an effect when the parent object is Private and the child is not Controlled by Parent

Controlled by Parent :

Controlled by Parent, in contrast, grants read or read-write access to the child records when access is granted to the parent. 

It has an effect in all parent share modes (private, read-only, and write).

Using Controlled by Parent will decrease row lock time on the parent, but not eliminate it. 

There has to be a lock on the parent while the children are being updated. 

Controlled by Parent will increase performance because there's no child share table while in this mode 

(the children's access is checked using the parent's share table).

Case share  :

If a portal or customer community plus user is a contact on a case,then the user has read and write access on the case.

The contact for a Case has Read & Edit Access on that Case.

Only affects Partner and Community Plus Licenses.

Community License Users need Sharing-Set.

Share Group (High Volume) :

Access to data owned by high volume users associated with a sharing set for users member of the sharing set's access group.

All members of the sharing set access group gain access to every record owned by every high volume user associated with that sharing set.

profile : Customer Community

Record Ownership by User is necessary.

Affects(almost?) all objects.

Record Owner needs Profile in share Set.

Any Record owned by a profile mentioned in the Share Set is shared with any user mentioned in the related share group.

Record Locks & Skews :

======================

Record Locks can happen

1.Business-related 

  Defined by business process and implemented intentionally (e.g.Approval Process,read-only record types).

2.System-related 

  Done by Salesforce, available and implemented out of the box (cannot be changed)

System Related Record Locks :

Quality of a database is often measured by its data integrity:

1.Data accuracy

2.Data Completeness

3.Data consistency

One measure by Salesforce (and many other databases) to maintain data integrity is to place record locks on records(and their parent records)

while they are being edited.

Note :

A given transaction can only wait a maximum of 10 seconds for a lock to be released,

otherwise it will throw and UNABLE_TO_ROW exception.

Data Skews :

In a database, a skew refers to a situation in which there is an uneven distribution of data.

Data Skews in Salesforce 

In salesforce, data skews happen when records relate to one another and child records are unevenly distributed across the parent records.

They will typically result in performance issues.

There are three kinds of data skews that can occur :

1.Account Skew

2.Ownership Skew

3.Lookup Skew

Lookup Skew :

Lookup Skew happens in object relationships when a large number of child records are associated to one parent record.

When a child record is inserted or updated, Salesforce locks the parent record the child will be associated to in order 

to maintain data inegrity.When you work with large data, and there are processes (e.g. custom code, automated processes, integrations)

you can easily run into lock contention.

Lookup skews happen in lookup relationships AND master-detail relationships.

Lookup skews can effect standard AND custom objects.

How to identify a Lookup Skew :

There is no exact identifier by which you will be able to identify a lookup skew .

Don't wait until somebody complains, try to address to problem right away.

Take a look at the following 

1.Objects with a lot of records.

2.Objects where a lot of inserts and updates happening in parallel.

3.Objects where you get complaints about locks from users.

How to avoid Lookup Skews?

1.Reduce Record Save Time (Apex Best Practices,Asynchronous Processing,Consolidate Automation).

2.Picklist fields.

3.Distributing the skew.  

4.Reducing the load (Serial loading, order by Parent Id and chunk the data carefully).

Account Skew :

An Account Skew arises, when a large number of child records (>10,000) are related to a single account.

There are two main problems that can be caused by an Account Skew:

1.Record Locking

2.Sharing Problems

Account skew - sharing problems 

Sharing problems arise because of Salesforce built-in parent implicit sharing.

(Users with access to contacts,cases and opportunities get read access to the related account).

If sharing of a child record of a certain object is updated, Salesforce will have to check all other 

children of that object to check, if the implicit share for the Account can be removed.

Depending on the amount of childern, the recalculation can take long and will cause performance issues.

During the whole operation, a lock is placed on the account preventing other from editing it.

How to avoid Account Skews?

Limit the amount of Account Children per object to 10,000.

If you need generic Accounts, create a pool of accounts and use a round robin algorithm to distribute them.

Consider setting the Account OWD to 'Public Read/Write'(The record locking 

Ownership Skew :

An ownership skew happens, if a single user owns more than 10,000 records of one object.

Performance issues caused by an ownership skew will most typically appear in large organisation where 

data chnages that require sharing recalculation happen frequently. These changes could happen on :

Ownership based sharing rules

Record ownerships

Group members/ Role Hierarchy

How to avoid Ownership Skews?

1.Ensure that the 'Skewed' owner is not part of the role hierarchy or put them in a role 

at the top of the hierarchy/ within its own branch.

2.Don't move the user into another role/move the role within the role hierarchy.

3.Keep the user out of public groups used for sharing.

4.For organization wide sharing, review OWDs(is private necessary?)

In Overall to avoid DataSkew :

Avoid Large number (>10,000)of child records in master/Detail relationship 

Avoid Large Number of records owned by one user

Avoid RecordLocking

Lightning Web Component Navigation Service

 The navigation service adds two APIs to your component's class. Since these APIs are methods on the class, invoke them from this.

1.[NavigationMixin.Navigate](pageReference,  [replace])

A component calls this[NavigationMixin.Navigate] to navigate to another page in the application.

ex :

navigateToObjectHome() {

        // Navigate to the account object home page.

        this[NavigationMixin.Navigate]({

            type: 'standard__objectPage',

            attributes: {

                objectApiName: 'Account',

                actionName: 'home'

            }

        });

    }

2.[NavigationMixin.GenerateUrl](pageReference)

A component calls this[NavigationMixin.GenerateUrl] to get a promise that resolves to the resulting URL. 

The component can use the URL in the href attribute of an anchor. 

It can also use the URL to open a new window using the window.open(url) browser API.

ex :

recordPageUrl; // variable to be associated to anchor tag.

 

// Generate a URL to a User record page

generateURLforLink() {

    this[NavigationMixin.GenerateUrl]({

        type: 'standard__recordPage',

        attributes: {

            recordId: '005B0000001ptf1XXX',

            actionName: 'view',

        },

    }).then(generatedUrl => {

        this.recordPageUrl = generatedUrl;

    });

}

// NavigationMixin.GenerateUrl returns the Generated URL in the promise.

// We can even use this in  window.open(generatedUrl) command.

Salesforce Shield

 Salesforce Shield is made up of three components.

1.Platform Encryption (Natively encrypt sensitive data)

2.Event Monitoring (Detailed data & Monitoring)

3.Field Audit Trail (Prevents Data loss)

Platform Encryption :

1.Encrypt sensitive data when it's stored at rest in the salesforce cloud.

it means encrypts data metadata layer at place where it is stored.

In database it stored in an encrypted manner.

2.Support customer-controlled encryption key lifecycles.

  Manage the lifecycle of data encryption keys.

  

Note :

Data stored in many standard and custom fields and in files and attachments can be encrypted using an advanced Hardware Security Module-based (HSM)

key derivation system, so it is protected even when other lines of defense have been compromised.

  

  

Tenant Secret Key :

Generated and rotated by customers. A New Tenant Secret can only be generated once every 24 hours in a production

organization and every 4 hours in sandbox environment. The option is disabled, if the Tenant Secret is generated in last 24 hours

in production and 4 hours in sandbox environment.  

Master Secret Key : 

Generated and rotated by Salesforce. 

Master secrets used in the key derivation function are rotated with each major Salesforce release.

How Platform Encryption works ?

The salesforce user submits a save request the first thing that gets invoked is the encryption service.

The encryption service checks if there is any encryption policy applied to that particular operation.

If yes it takes in the cache if there is a encryption key available for encryption.

If not it sends a request to the key derivation server which generates a key of the tenant secret which 

is generated in the particular org.

The Master secret which is generated at the start of every release by salesforce itself.

so it generates a encryption key and it sends it sends back to the encryption service.

Now as soon as the encryption service receives the encryption key it generates a random initialization vector

which is used to encrypt the data.The data which is encrypted and the initialization vector against that particular

operation gets stored in the salesforce.

Probabilistic Encryption :

By default, Salesforce encrypts data using a probabilistic encryption scheme.  

Probabilistic encryption is the use of randomness in an encryption algorithm so that when encrypting the same text several times,

it will, in general, yield different cipher texts.

Probabilistic encryption is so secure that it can often cause issues when logic is executed in the database or when encrypted values are compared to a string or to each other.  When these types of configuration

changes are made within a Salesforce org, filtering isn’t possible because the data has been turned into random, patternless strings. 

For example, you might run a SOQL query in custom Apex code against the Contact object, where LastName = ‘Jones’.

If the LastName field is encrypted with probabilistic encryption, you can’t run the query because each instance of the value 

‘Jones’ represents a different text string. 

It is recommended to use probabilistic encryption whenever data in a field will not need to be filtered on.

Deterministic (Filter-Preserving) Encryption

Deterministic encryption addresses the issue with probabilistic encryption by securing the Salesforce org while retaining the 

benefits of filtering data. 

To be able to use filters when data is encrypted, we have to allow some patterns in our data.  

Deterministic encryption uses a static initialization vector (IV) so that encrypted data can be matched to a 

particular field value.  The system can’t read a piece of data that’s encrypted, but it does know how to retrieve 

the cipher text that stands for that piece of data because of the static IV.  The IV is unique for a given field in a given org 

and can only be decrypted with your org-specific encryption key.  The Salesforce Shield Platform Encryption at rest approach 

is to expose just enough determinism to enable users to filter on encrypted data while limiting it enough to ensure that a 

given plain text value does not universally result in the same cipher text value across all fields, objects, or orgs.  

In this way, deterministic encryption only decreases encryption strength as minimally necessary to allow for filtering.

Deterministic encryption allows for the user to specify if case sensitivity on record values needs to be accounted for 2 Types

of Deterministic Encryption:

Case-Sensitive – Allows for the ability to filter data on a case-sensitive basis. ‘ACME’ and ‘Acme’ will be 

considered 2 unique values and the encryption scheme would use different cipher text strings to identify these 2 records.

Case-Insensitive – Allows for the ability to filter data but does not factor the case of the value. ‘ACME’ 

and ‘Acme’ would be considered the same value and the encryption scheme would use the same cipher text value 

for both (assuming the record is in the same field / object / org)

Note :

What’s Data Encryption?

Data encryption is the process of taking information in readable form and translating it to a non-readable form.  

It converts data into a secret code and is the most effective way to achieve data security.  To read an encrypted file, 

you must have access to a secret key or password that enables you to decrypt it.

Unencrypted data is called plain text; encrypted data is referred to as cipher text.  

When data is encrypted, each bit of data is turned into a fully random cipher text string.  

Encryption will not generally impact users who are authorized to view the data.

Deterministic(Static IV)

ex :

   value      cipher Text

   BOB           1234az96

   BOB           1234az96

Probabilistic(Random IV)

ex :

   value      cipher Text

   BOB           1234az96

   BOB           6924wh12

Event Monitoring :

1.Monitor data loss

2.Increase adoption

3.Optimize performance

Event monitoring lets you to easily see what data users are accessing, from what IP address, and the actions done to that data.

e.g. API calls, user logins, users who are running reports, exporting reports, downloading files, and etc.

Event Monitoring data can be accessed via the API.

Use the SOAP API and REST API resources to retrieve event log files that contain information useful 

for assessing organizational usage trends and user behavior.

You can track up to 28 different event types. Log data is read only. You can’t insert, update, or delete log data.

You can access those data via API and pull the data into any visualization tools. For example Salesforce Analytics.

Field Audit Trail :

1.with up to 60 fields per object selected for tracking changes.

2.Tracked changes may be displayed in a related History list.

3.Stored in a related object for upto 18 months.

Note : Any historical data that is captured before platform encryption

was enabled is still in readable state.it is not encrypted.

Any data that was created or updated prior to enabling platform encryption

that is still in readable mode. If you want to get it encrypted we need to reach salesforce.

User with "Manage Encryption Keys" Permission can generate,export,import and destroy organization-specific keys.

Monitor the key management activities of these users regularly with the setup audit trail.

Protected fields are only visible to the users who have the “View Encrypted Data” permission. Encrypted data can only be accessed with appropriate Tenant Secret.

Considerations :

1.Custom Fields - You can't use encrypted custom fields in criteria-based sharing rules,filtering or sorting contexts.

2.SOQL/SOSL - Encrypted fields that use encryption scheme can't be used with aggregate functions & few SOQL and SOSL clauses.

3.Portals - If a portal is enabled in your organization,you can't encrypt standard fields.

If legacy portals are active, shield platform encryption can't be enabled.

4.Field Audit Trail - Data in a previously archived Field Audit Trail isn't encrypted when you turn on Platform Encryption.

5.Apps like Commerce cloud, Quip, Marketing Cloud, Salesforce CPQ etc. don't support data encrypted with Shield Platform encryption.

Platform Encryption :

===================== 

1.Advanced Settings :

For encryption policy tasks, also require that admins have the Manage Encryption Keys permission.

Deterministic Encryption

Use deterministic encryption when you want to filter on encrypted data. 

Apply this scheme to specific fields from the Encryption Policy page.

Allow BYOK to Opt Out of Key Derivation

Lets you disable Salesforce’s key derivation process, and use your uploaded key material as the final data encryption key.

Encrypt Custom Fields in Managed Packages

Lets you encrypt custom fields in installed managed packages.

Encrypt Field History and Feed Tracking Values

Includes field history and feed tracking changes in data encrypted during the synchronization process.

2.Encryption Policy 

Shield Platform Encryption also supports custom fields in installed managed packages. 

Apply encryption to custom fields from the management settings for each object. 

For best results, encrypt the least number of fields possible. When you add encryption to a field, all new data in that field is encrypted.

3.Encryption statistics :

we get to know that the data which already exists is encrypted (or) not.

which records in my org are encrypted and how many are still in readable state.

we can gather statistics once in every 24 hours.

4.Key Management

Salesforce allows us to generate a tenant secret or else we can go ahead and import our own key which is generated by some other external systems.

Note :

As soon as generate a new key, the first key becomes archived.

All 50 keys available in org, of which only one can be active either could be archived or destroyed state.

Sharing and Visibility in Salesforce

Most objects in Salesforce have associated sharing objects.

Standard objects have associated sharing objects with the word share appended to them.

 ex : AccountShare,ContactShare

Custom objects also have associated sharing objects with the word __share appended next to the name.

  ex: Robot__share

For a custom object called Robot, Robot__share will hold sharing records for that object.

Standard sharing objects differ from each other, but have very similar fields.

ex:

Opportunity :

The OpportunityShare object has a field called Opportunity, which is a lookup to Opportunity.

Every row in the sharing object corresponds to exactly one Opportunity record, and this lookup holds the ID of that record.

UserOrGroup :

We have another field called UserOrGroup. This is a lookup to either a user or a group the related opportunity is being shared with.

OportunityAccessLevel :

OpportunityAccessLevel holds the access level granted as a result of this row. Read, which grants read access, Edit, which grants edit access,

 and All, which grants full access including edit, transfer, delete, and sharing rights are three possible values in this field.

 

 e.g.  Read,Edit and All

 

RowCause :

RowCause holds the reason this row exists in the sharing object.Record owners get a row in this object with all access by virtue of being owners.

Sharing rules end up creating rules with RowCause rule. Manual shares also result in roles in this object with the RowCause Manual. 

There are many other possible values for RowCause which can differ by object

e.g. Owner,Manual or Rule

Other standard sharing objects have similar fields, but may have differences.

Let's take AccountShare as an example. It has the fields you would expect, Account, UserOrGroup, AccountAccessLevel, and RowCause. 

You find similar fields on almost every standard sharing object, but there's also some fields you did not expect. 

This includes CaseAccessLevel, ContactAccessLevel, and OpportunityAccessLevel fields. This is because of implicit sharing behavior in Salesforce. 

When the user gains access to an account, depending on the account owner's role and OWD settings, the user can also gain implicit access to children cases, contacts, and opportunities.

These fields capture the access level that should be given to these related records.

Custom objects get their own sharing object too, and they are simpler than the standard ones because all of them have the same fields.

Let's talk about Robot__Share, which would be the sharing object for a custom object named Robot. 

The sharing object will have a field called Parent, which is a lookup to the parent robot record. 

It will have a field called UserOrGroup, which would be a lookup to the user or group the record is being shared with. 

The FieldAccessLevel with values Read, Edit, and All just like the standard share objects will also be present. And finally, the field RowCause, 

which stores the reason this row exists.

Note :

Inserting share records for the same parent, same user, and same RowCause as an existing share results in an update of the existing record, not a new insert.

Facts about Sharing object :

1.There are cases when sharing objects are just not available.

 e.g. An object has public read/write OWD.

2.This makes sense because such an object wouldn't need any sharing. An object on the detail side of a master‑detail relationship is another example.

This is because such an object inherits sharing from its master and cannot have its own sharing model.

 e.g. Master-details

3.Some objects have their own access control mechanisms such as tasks, events, or files and hence do not have a sharing object available.

Sharing objects don't give a complete picture of why a user may be seeing a record.

1.Access given out through the role hierarchy is not shown in sharing objects.

2.Access given out through organization by defaults is not tracked in this object.

  Everyone can see records of a public read-only object, but you won't see any sharing records and sharing tables.

3.Access given out through record‑level profile and permission set settings, such as view all and modify all settings, is also not tracked in sharing objects.

Roles: They're Just Groups :

Setting up the role hierarchy results in a few things behind the scenes.

Salesforce creates two groups for each role that we have defined.

Every role gets a Role group and a RoleAndSubordinates group.

Note : Salesforce creates two Groups for each role 

 --> Role Group

 --> RoleAndSubordinates group

You may have seen these special groups when creating sharing rules, queues, or public groups. 

That's when Salesforce gives you the option to share records with a role or with roles and subordinates.

RoleAndInternalSubordinates group:

There is also a third group that Salesforce would create for every role known as the RoleAndInternalSubordinates group, 

but this is only when Digital Experiences and external org-wide defaults are enabled in your org.

In case these options are enabled, this group excludes partner and customer portal users.

Group object :

We can actually look at these groups(Role Group,RoleAndSubordinates group,RoleAndInternalSubordinates group) in the Group object.

SELECT Id,DeveloperName,Type FROM Group

If you run the above SOQL query you can see the Role and RoleAndSubordinate groups defined for each role.

You can see there are two groups.One is of the type Role, and other is of the type RoleAndSubordinates.

Role group  :

A Role group has all members assigned that role as direct members, but also all users assigned a higher role as indirect members of that group.

Note : 

Role Contains users with the given role as members, and everyone with higher roles as indirect members.

RoleAndSubordinates group :

Contains users with given role and subordinate roles as members, and users with higher roles as indirect members.

Note : Both these groups contain users with higher roles as indirect members.

GroupMember Object :

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.

Note :

These "group maintenance" records in conjunction with "sharing" records allow Salesforce to get results fast.

Profile and Permission Set Settings :

View All Data :

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.

Modify All Data :

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 All (Object-level)

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. 

Modify All(Object-level) :

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.

 

Sharing Calculations and ReCalculations  :

Sharing Calculations :

Calculations Salesforce performs behind the scenes to ensure a rapid application

of sharing and visibility any time someone requests records from the database.

Note : 

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.

Recalculations Scenarios :

1.Adding, removing or editing a sharing rule.

Asynchronous

 -> Can be seen on the background job page

 -> Email when completed

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.

3.Changing OWD settings

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.

Note :

-> 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. 

The sharing rules will have no impact of course, but they still exist. 

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 

because the sharing rule now needs to be re calculated. 

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.

-> Changes to role Settings 

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.

securely share files,reports and dashboards in Salesforce

 sharing Salesforce Files :

1.File are just digital documents that can be uploaded to Salesforce.

2.Files can be shared with users or groups, and you can even create a public link that allows you to share them with people outside of your company.

3.Files can also be stored in private libraries or even marked as private when they are attached to a record.

4.Files such as images or PDFs can be previewed without having to be downloaded.

5.Replace old way of managing files in Salesforce classic.

Note : Salesforce Files is the way to organize your documents in Salesforce. 

Files in Salesforce Classic :

1.Classic Notes 

Classic notes, as they are now referred to, allowed users to write a brief text‑based note and attach it to a record, such as an opportunity or an account.

2.Attachements 

Users also had the option of attaching actual files, such as a Word or PDF document, to a Salesforce record.

3.Documents

users could upload actual documents to a document repository, but these files were separate from notes and attachments.

Ways to Share Files :

1.Chatter feed

you can post them to a Chatter feed.

2.Users and Groups

 You can also share them with specific users and groups

3.Public link

To collaborate with external users or customers, you can create publicly accessible links.

4.Attach to record

you can attach a file to a record.

Note :  All of these files can be managed From one central repository

Files Home :

Files Home is the place where you can easily manage all your Salesforce files.

 Files home allows you to search for files that you either own or can access.

 You can even preview files without having to download them first.

 If necessary, you can upload private files that will be marked as private.

 Once uploaded, you can share files with users, groups, or with a public link.

 

 Assignable File Permissions :

 

1.Viewer

The viewer permission indicates that the user can view, download, and share a file, along with being able to attach a file to a post.

  

2.Collaborator

A collaborator can also do these things, along with a few other things.

Viewer Vs Collaborator :

Viewer :

1.View or preview

2.Download

3.share

4.Attach file to post

Collaborator :

1.View or preview

2.Download

3.share

4.Attach file to post

5.Upload new version

6.Edit details

7.Change permission

Note :

A viewer can view or preview a file, download, share, or attach the file to a post.

A collaborator can do all of those same things, but they can also upload a new version, edit file details, and even change permissions for files that have already been shared.

A super important thing for you to realize is that if a user has been granted the Modify All Data system permission, they can access files they do not own, regardless of whatever permission has been assigned to them.

(or)

Users with " Modify All Data" permissions can access files they do not own.

Users with " vIew All Data" permission can view files they do not own.

Private Files :

Private indicates that the file has not been shared with anyone other than the owner.

The File Privacy on Records option lets you control the visibility of a file when it's attached to a record. 

If you don't see the File Privacy on Records option when you edit a file's details, ask your admin to add it. 

Only admins and file owners can change the value of File Privacy on Records.

Sharing Reports and Dashboards :

1.Viewer

Viewer access allows users to view reports or dashboards and see what level of access has been granted to that folder.

2.Editor

Editor access allows the users to also save, rename, or delete reports or dashboards in a folder.

3.Manager

And manager access grants the additional ability to share a folder, as well as change the folder's name, or even to delete that folder.

System Permissions :

By default, Salesforce users will have access to a My Personal Custom Reports folder and a My Personal Dashboards folder from where they create and customize personal reports and dashboards.

Summary :

Files can be uploaded and shared from :

1.Files Home

2.Chatter feeds

3.Object records

4.Public links

Uploading to record requires adding Files related list to objects page layout.

Files uploaded to home - private by default.

Beware modify/view All Data permissions.

Mark as private or move to private library to ensure privacy.

reports and dashboards :

Permissions for reports/dashboards controlled through folder access.

Set at the root level for nested folders.

Note : Even though you can have nested folders, access is set at the root folder level.

Each usr has access to :

-My Personal custom reports.

-My Personal dashboards

Note : Each internal user will have access to a my personal reports folder for custom reports and one for personal dashboards.

Team Sharing and Grant Access in Salesforce

 Account Team :

1.Account team is a group of users all working on the same account.

2.Account team cannot be the owner.

3.Account team will need object level read/write access.

Team Roles :

For Accounts, Opportunities and cases , record owners can use teams to allow other users access to their records.

Record owners can build a team for each record that they own.The record owner adds team members and specifies the

level of access each team member has to the record.

In account teams , team members also have access to any contacts,opportunities and cases associated with an account.

Case Team :

Case Team is a group of users all working on the same case.

Case record exists as a part of an account record.

Case Team cannot be the owner.

The goal of a Case Team is to resolve the case as soon as possible.

Very similar to Account Team, however the setup is quite different.

Sales Team :

1.A Sales Team is a group of users working on an opportunity or an account.

2.Sales Team and Account Team members often have access to the same records.

3.Sales Team cannot be the owner.

4.Unser Account Team roles is where you also access Sales Team roles.

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.