Sharing Rules Recalculation

 1.Manual Sharing Rule Recalculation (Parallel Calculation)

2.Auto Sharing Rule Recalculation (One by One Calculation)

Manual Sharing Rule Recalculation (Parallel Calculation) :

whenever a sharing rule is recalculated manually, it is always done in parallel meaning all sharing rules calculation 

would start together and would run simultaneously.

If the number of records that are impacted by the recalculation are less than 25k or 25000 then in this case 

you would not receive an email upon completion of the recalculation.

We can track Manual Sharing Recalculation activity in the 'Background Jobs'.

we will find the start time along with the specific sharing criteria , percentage completed and the end time.

Note :

Manual sharing recalculation or parallel recalculation is faster than the Auto Sharing recalculation.

Auto Sharing Rule Recalculation (One by One Calculation) :

The Auto Recalculation of sharing rules is when some activity triggers the modification to the sharing rules and 

so a recalculation is done for the same by Salesforce without explicitly clicking on Recalculate button.

This happens when for example a record type is deleted or there is a change in the Role Hierarchy or any activity 

that sees a modification in the sharing rules. As soon as the activity is performed, Salesforce itselves starts the 

recalculation of the sharing rules for the whole org, this is done in a one by one mode meaning only one sharing rule at a time.

As only one sharing rule is calculated at a time it takes quite a long time depending on your org data.

To get an estimate of how much time would it take to recalculate the Sharing Rules on your org, 

Salesforce suggests that you run the same on a full copy sandbox. Ideally the time taken on the Full Copy sandbox 

is a replica of how much time it would take on your production instance.

Defer Sharing Calculations:

Deferring sharing calculation is ideal if you make a large number of changes to roles, territories, groups, users, 

portal account ownership, or public groups participating in sharing rules, and want to suspend the 

automatic sharing calculation to a later time.

Relationships In Salesforce

 

1. Lookup relationship

Parent record is not required when creating a child record as parent and child objects are loosely coupled.

Lookup relationship does not support roll-up summary field.

Lookup fields are not required on the page layout of the detail record but if you make them a required field, it is advised!

Standard object record can be on the detail side of a custom object in a lookup relationship.

By default record ownership of child records is not controlled by the parent.

Can have a child record without a parent.

Can have a maximum of 40 lookups on an object.

No cascade delete.

2. Master-detail relationship

Parent record is always required when creating a child record. That means parent and child object are strongly coupled.

Master detail relationship support roll-up summary field.

Parent record is required in order to save a child record.

Master-detail field is always required on the page layout of the detail record.

Standard object record cannot be a child.

The parent controls the record ownership of child records. The owner field is not available on the detail record in master-detail relationship queues, sharing rules and manual sharing is not possible for detail records as it requires the owner field.

You cannot have a child record without a parent.

You can have a maximum of two master details on an object.

Cascade delete.

 

3. Many-to-Many Relationships: 

If there is need to create the many-to-many relation then we need to use the Junction object in Salesforce. A junction Object is a type of custom object which allows linking two custom objects.

A junction Object in simple terms can be called a custom object with two master details fields.

Records of a particular object can connect with various records of different objects and vice versa.

 

4. Self-Relationship:

It means an Object is creating a relationship with itself. 

It creates a tree diagram of the objects.

 

5. Indirect lookup relationship:

This allows a relationship to be formed between a SF object and an external object. If your Salesforce org was the family, then the objects would be related but not in the same family. A great example of such is relating payment records to an account from an ERP system–the ERP system is external to Salesforce but the records are important. The way they relate is via an external ID to match the payments to the account.

External lookup relationships- allow a relationship to be formed between two external objects. Your two friends from outside of your group are now in a relationship. Maybe that ERP system links the payment records to a bank account.

6. Hierarchical Relationships:

This unique relationship can only be used on the user object and is designed to create a hierarchy of users. For example, it could be used to create a lookup field for the user object, which can be used to list the user’s manager.