Before moving forward with relationships have an basic understanding of what are Objects, Apps, Tabs and fields in salesforce.

Objects in Salesforce:

In Salesforce, an object is a table that stores data related to specific information. Objects are used to organize and manage data in Salesforce, similar to how a database uses tables to store information. Salesforce objects allow you to store information on various entities, such as customers, leads, or transactions, and then interact with that data through standard operations like create, read, update, and delete (CRUD).

There are two types of Objects in salesforce

1. Standard Objects:

   These are pre-defined objects in salesforce. They cover the core/typical CRM functions and include objects like.

   • Account: Stores information about companies or individuals involved in your business.

   • Contact: Stores individual people associated with an account.

   • Opportunity: Tracks sales deals in progress.

   • Lead: Represents a potential sales opportunity.

   • Case: Tracks customer issues and support requests.

2. Custom Objects:

• These are objects you can create to store data that is specific to your business needs. For example, if your organization deals with properties, you might create a custom object called "Property" to track information about various real estate assets.

• Custom objects can be fully customized in terms of fields, relationships, and permissions.

Objects can also have:

• Fields: Individual data points on the object (e.g., First Name, Email, Address).

• Records: Instances of the object (e.g., a specific customer or lead).

• Relationships: Objects can be related to each other (e.g., an Account can have many Contacts associated with it).

Objects form the foundation for data storage and structure in Salesforce, making them central to how the platform operates.

What are Relationships in Salesforce ?

It is kind of similar concept in DBMS where we try to establish an relationship between all the entities/tables. Think of database schema of library management system.

In Salesforce, relationships define how two objects relate to each other. They help in establishing connections between records stored in different objects, allowing you to track and organize related data. There are several types of relationships in Salesforce.

NOTE : In Salesforce on a single object we can create max 40 relationship fields. It keeps on changing as salesforce keep’s updating it.

Master-Detail Relationship:

• A Master-Detail Relationship in Salesforce is a type of relationship that tightly links two objects, where one object (the Detail) is dependent on another (the Master) for its existence.

• This relationship establishes a parent-child connection between records, with strict rules around data sharing, deletion, and ownership.

Key Characteristics of Master-Detail relationship:

1. Tightly Coupled

2. Ownership and sharing: The detail record inherits the sharing and security settings of the master record. The detail record does not have its own owner; it shares the same owner and visibility rules as the master record.

3. Field Requirements: The detail object has a required field linking it to the master object.

4. Cascade Delete

Behavior of Master-Detail relationship:

• Deleting a detail record moves it to the Recycle Bin and leaves the master record intact. Deleting a master record also deletes related detail and sub-detail records. Undeleting a detail record restores it, and undeleting a master record also undeletes related detail and sub-detail records. However, if you delete a detail record and later separately delete its master record, you can’t undelete the detail record, as it no longer has a master record to relate to.

• By default, records can’t be reparented in master-detail relationships. Administrators can, however, allow child records in master-detail relationships on custom objects to be reparented to different parent records by selecting the Allow reparenting option in the master-detail relationship definition.

• The Owner field on the detail and sub-detail records isn’t available and is automatically set to the owner of the master record. Custom objects on the detail side of a master-detail relationship can't have sharing rules, manual sharing, or queues, as these require the Owner field.

• Detail and sub-detail records inherit security settings and permissions from the master record. You can’t set permissions on the detail record independently.

• The master-detail relationship field (which is the field linking the objects) is required on the page layout of the detail and sub-detail records.

• The master object can be a standard object, such as Account or Opportunity, or a custom object.

Example Use case:

Let’s say you are using Salesforce to manage a Sales Order system. You might have

• Order (Master): Represents a sales order, storing data like order number, date, and customer information.

• Order Line Item (Detail): Represents individual products or services sold as part of the order. These records can only exist if they are linked to an Order record.

Lookup Relationship:

• A Lookup Relationship in Salesforce is a loosely coupled relationship between two objects, where one object can reference another.

• This type of relationship allows you to relate one object to another, but without the strict dependency found in a Master-Detail Relationship.

• Each record can exist independently of the other, meaning that records in the lookup (child) object do not require the existence of a record in the parent object to function.

• Lookup relationship can also have cascade delete behavior but it is optional.

Key Characteristics of lookup relationship:

1. Loosely Coupled:

   • The objects are related, but they are independent of each other. Deleting a parent record does not automatically delete the related child records (though you can configure "cascade delete" as an option).

2. Optional or Required:

   • A lookup field can be optional or required. If optional, the child record can exist without having a parent record. If required, the child record must reference a parent record, but this dependency is not as strict as in a master-detail relationship.

3. Multiple Relationships:

   • You can create multiple lookup relationships for a single object. This allows you to link multiple related records from different objects to one main record.

4. Independent Sharing and Ownership:

   • Lookup records maintain their own ownership, sharing settings, and security, independent of the related record. The child record does not inherit the sharing rules or ownership of the parent record.

5. Reparenting:

   • In a lookup relationship, you can easily reassign or change the related parent record by updating the lookup field in the child record.

6. Hierarchical Relationships:

   • A special type of lookup relationship, available only on the User object, where one user can be linked to another in a hierarchy (e.g., manager to employee). We will discuss this relationship further in detail.

Example Use case:

Let’s consider a Case management system. You might have:

• Case (Parent): Represents customer issues or support tickets.

• Contact (Child): Represents individual contacts or customers who have reported the case.

In this scenario, the Contact (child) can be linked to a Case (parent) through a lookup relationship. However, if the case is deleted, the contact still exists independently. The contact record remains in the system, and there’s no automatic deletion of related cases.

Note: Lookup fields allow you to associate two records together in a relationship.

When to Use a Lookup Relationship:

• When objects are related but should function independently.

• When deleting a parent record should not automatically delete related child records.

• When you don’t need the child object to inherit sharing rules or ownership from the parent object.

Hierarchical Relationship:

• A Hierarchical Relationship in Salesforce is a special type of Lookup Relationship available exclusively for the User object.

• It allows one User record to be related to another User, typically representing a hierarchy or reporting structure within an organization, such as managers and subordinates.

Key characteristics of Hierarchical Relationship:

1. Available Only on the User Object:

   • This relationship is specifically designed for the User object in Salesforce and can't be applied to other standard or custom objects.

2. Self-Referencing Lookup:

   • A Hierarchical Relationship is essentially a self-referencing lookup field. It creates a link between one user and another user, typically used to show the manager or supervisor relationship.

3. Not a Master-Detail Relationship:

   • Unlike a master-detail relationship, there is no strict dependency between the two users. Deleting one user does not affect the other in the hierarchical relationship.

Example Scenario:

Consider a company where:

• User A is a manager.

• User B and User C report to User A.

Many-To-Many Relationship

A Many-to-Many Relationship in Salesforce allows multiple records of one object to be related to multiple records of another object. Salesforce does not directly support a many-to-many relationship natively between two objects instead, it is implemented using a third object called a Junction Object.

What is Junction Object?

• A Junction Object is a custom object that sits between two other objects to facilitate the many-to-many relationship.

• It contains two Master-Detail Relationships, each pointing to one of the objects you want to link.

• This junction object acts as a bridge between the two objects, allowing each record in the first object to be related to multiple records in the second object, and vice versa.

In Salesforce, when you create a Many-to-Many Relationship using a Junction Object, you establish two Master-Detail Relationships between the junction object and the two parent objects.

One of these Master-Detail Relationships becomes the Primary Master Relationship, and the other becomes the Secondary Master Relationship.

1. Primary Master Relationship:

   • The Primary Master dictates ownership, sharing, and security settings of the Junction Object records. This means that the junction object (child) record will inherit the owner and sharing rules from the primary master record.

2. Secondary Master Relationship:

   • The Secondary Master does not control ownership or sharing settings of the junction object record.

Example Scenario:

Let's say you Course and Students Object:

• Course (Master Object 1)

• Student (Master Object 2)

• Course Enrollment (Junction Object)

In this case, the Course Enrollment junction object would have two master-detail relationships: one to Course and one to Student. Depending on the nature of your application, you might decide which one should be the Primary Master.

• Primary Master: If Course is selected as the primary master, the ownership and sharing settings of the Course Enrollment records will follow the ownership and sharing rules of the Course object.

• Secondary Master: The Student object in this case would be the secondary master, meaning the Course Enrollment records will still be related to students, but ownership and security will not be inherited from the Student object.

Self Relationship:

A Self Relationship is a lookup relationship where an object has a relationship to itself. It’s useful when a record can relate to other records of the same type.

• Example: An Account record can have a lookup relationship to another Account record to establish a parent-child account structure.