Types of relationship in Salesforce

---

You can establish relationships between objects in Salesforce. You can associate one object with another. For example, you have an object named Meetup (to store information about a meeting), and you want to associate it with another object, Participant (to store information about participants for a particular meeting) so that you can associate the Participant records with the respective Meetup record. These relationship types also determine how they handle record sharing, data deletion capability, and required fields in page layouts. Salesforce provides the following object relationship types that can be established among objects:

• Master-detail relationship
• Lookup relationship
• Self-relationship
• External lookup relationship
• Indirect lookup relationship
• Many-to-many relationship (junction object)
• Hierarchical relationship

Master-detail relationship

It is a strongly coupled relationship among Salesforce objects, which means if a master record gets deleted, then the child records associated with it are also deleted. In this type of relationship, the parent record controls the behavior of the child record regarding visibility and sharing. It means the security setting of a parent object applies to the child object.

For example, if we create a master-detail relationship between the Meetup and Participant objects, where Meetup will act as the parent object and Participant will serve as the child object, then if someone deletes a Meetup record, all the associated Participant records will also get deleted.

When there is a master-detail relationship between two objects, you can create a unique type of field over the master object, called Roll-up summary. A roll-up summary field allows us to calculate values from child records, such as the number of child records linked to a parent record.

Tip

For best practice, don’t create more than 10,000 child records for a master-detail relationship.

Lookup relationship

It is a loosely coupled relationship among Salesforce objects, which means even if a parent record gets deleted, the child records remain in the system. Here, both the parent and child have their own sharing settings and security controls. The following image gives a visual representation of the lookup relationship between Meetup and Participant objects and what happen when parent (Meetup) record gets deleted:

For example, if we create a lookup relationship between the Meetup and Participant objects, where Meetup will act as the parent object and Participant will serve as the child object, then if someone deletes a Meetup record, all the associated Participant records will still exist in the system.

Difference between master-detail and lookup relationships

Let’s have a look at the differences between the lookup and master-detail relationships in the following table:

Lookup relationship	Master-detail relationship
Loosely coupled.	Strongly coupled.
Roll-up summary field cannot be created.	Roll-up summary field can be created.
Parent record is not required while creating a child record.	Parent record is always required in order to create a child record.
Lookup fields are not required on the page layout of the detail record.	Master-detail field is always required on the page layout of the detail record.
Standard object record can be on the detail side of a custom object in a lookup relationship.	Standard object record cannot be a child.
By default record ownership of child records is not controlled by the parent.	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 can have a child record without a parent.	You cannot have a child record without a parent.
You can have a maximum of 40 lookups on an object.	You can have a maximum of two master details on an object.
No cascade delete.	Cascade delete.

Self-relationship

Self-relationship is another example of a lookup relationship. In Salesforce, we can use lookup relationships to create self-relationship among objects; we can have a maximum of 40 self-lookups. For example, a campaign record can have a Parent Campaign record.

External lookup relationship

We can create two special lookups on an external object apart from the standard lookup relationship. They are external lookup relationship and indirect lookup relationship.

External lookup relationship allows us to link an external object to a parent external object whose data is stored in an external data source. In other words, it allows us to link two external objects.

Indirect lookup relationship

An indirect lookup relationship allows us to link an external object to a standard or custom object. We can only create an indirect lookup to an object with a unique external ID field on the parent object that is used to match the records in this relationship. While creating an indirect lookup relationship field on an external object, we have to specify the child object field and the parent object field to match and associate records in the relationship. For example, we can display a related list of payments from the ERP external record with matching external IDs on the account object.

Many-to-many relationship

The many-to-many relationship in Salesforce allows us to link a child record to multiple parents. For example, a campaign is attached to many leads, and one lead may have more than one campaign.

If you have two objects, called Case and Article, and you want to relate these two objects in such a manner that one case can have multiple articles and one article is linked to many cases, then we have to use the many-to-many relationship. The many-to-many relationship is made with the help of a junction object. In this case, we can create the third object, let’s say, Solution with two master-detail relationships with Solution – Case and Solution – Article.

Note

One object can have only two master-detail relationships.

Hierarchical relationship

In Salesforce, only a user object has this type of relationship where we can create a hierarchy of users in the organization. For example, a user can have his manager, and his manager may have senior manager, and so on till the CEO or CIO level.