Types of Relationships in Salesforce: Master Detail Relationship
2 min
Many features make Salesforce the premier Customer Relationship Management (CRM) Platform in the world. Often those features make for exciting demos and headline-generating functionality. However, Salesforce really built itself into a giant by nailing the core infrastructure that serves as the foundation for the organization’s highly customizable CRM.
One of these key fundamental components is the relationship between objects and records. This is the “secret sauce” that enables Salesforce users to do things that simply can’t be done in a table – even one as advanced as Excel – and certainly not with the multitude of run-of-the-mill CRM competitors. Only a few of Salesforce’s top contenders provide the ability to create complex data models through relationships. While the concepts are simple, the work that can be done with them is not. This article discusses the specifics of the relationship options in Salesforce.
Primary Relationships between Salesforce objects and records
There are four primary relationships in Salesforce.
Master Detail Relationship: formal relationship between a parent object and its child or children. The child record can only have one parent and cannot exist without it.
Lookup Relationship: similar to Master Detail, but without the requirement to have an exclusive parent. Records in a lookup relationship can exist without having a parent (unless customized to require it).
External Lookup: relationship between a record within Salesforce and a record outside of the system. For an External Lookup, the external object is the parent.
Indirect Lookup: relationship between a record within Salesforce and a record outside of the system. For an Indirect Lookup, the Salesforce object is the parent.
- Four primary relationships in Salesforce:
- Master Detail Relationship
- Lookup Relationship
- External Lookup
- Indirect Lookup
Each of these relationships has several capabilities as well as limitations. The following section will cover each in more detail. There are few “bonus” relationships that are worth mentioning here as well.
Junction Object: this is a specific type of Master Detail Relationship. A junction object – which is the child – has two Master Detail Relationships, one each with two different parents. This is useful in creating a many-to-many relationship between the parent objects.
Self Relationship: this is a specific type of Lookup Relationship. When an object has a reason to lookup to itself, this is a Self Relationship. A common example of this would be an Account with a Parent Account. The child account has a lookup relationship to another account.
Master-Detail Relationship
The simplest explanation of when to use a Master Detail Relationship is when the child record would exist without the parent. For example, let’s say we are building the CRM for a movie theater chain. The chain has 100 movie theaters across the country. Each one of those theaters has between 5 and 25 auditoriums, and they want to track several aspects of the business including ticket revenue by theater and by auditorium. In this case, the auditorium is the child and has a Master Detail relationship to the theater. If the theater didn’t exist, neither would the auditorium. Because of this, that relationship field is always required to be populated.
Security, Ownership, Deletion, and Reparenting
The child record will also inherit its security and ownership from the parent as well. In the scenario above, whoever owns the Theater record would also own the Auditoriums in it. Likewise, users who have the ability to Create, Read, Edit, and/or Delete Theaters could also do so with Auditoriums. Although, very recently the Salesforce has added an option to slightly differ security settings between parent and child (the default is still to match). See the Sharing Setting options below. Children records can’t have unique sharing rules, manual sharing, or queues – they inherit all of these from the parent.
Since the child record can’t exist without the parent, deleting the parent would subsequently delete all of the children as well. This fits with our scenario, too. If unfortunately a movie theater is torn down, the auditoriums will be part of the demolition. However, Salesforce Administrators do have the ability to make a child record eligible to be reparented. This would need to occur before the parent record is deleted. Check “Allow Reparenting” on the field. While a parent is still required, it can now be changed. Since it would physically impossible to transport a movie auditorium into a new theater, we would probably leave this one unchecked.
Salesforce keeps deleted records for a period of time in the Recycle Bin. When a deleted record is still in the Recycle Bin, you can restore it as long as you’ve done it within the time period (two weeks). For the child in a Master Detail, you can delete it and restore it back to its parent. If you delete the parent and therefore all of its children, restoring the parent will also restore the children with it. However, if you delete a child record, then separately delete the parent, and try to restore them, the parent will come back but not the child since it was orphaned during the deletion process.
Roll-up Summaries and Formula Fields
Because this relationship type is so solid, it comes with highly beneficial Roll-up Summary fields. This allows the parent to add fields that function to sum, count, and find minimum/maximum values on the child records.
In our example, let’s say that Auditoriums have a field called “Number of Seats”. We could create a roll-up summary on the Theater object that sums up all of the seats in all of the Auditoriums in that theater. We could also use Max to figure out which Auditorium has the most seats and Min to determine the one with the least. The count function would let us quickly tabulate the number of auditoriums in the given theater.
These features can be filtered too. So for example, we can use the count up the auditoriums that have a special feature like 3D or surround sound. Perhaps we also want to know how many total (sum) seats we have in 3D auditoriums, or which 3D auditorium has the most seats (max).
It is worth noting that Roll-up Summaries cannot roll-up formulas. So if the child record has a formula field calculating a value, that can’t be summed or counted, etc. A work-around – which works in some cases – is essentially to Roll-up the values that comprise the formula and then perform the calculation on the parent record instead.
In addition to rolling information up to the parent, we can also pull record details down to the child from the parent. A simple formula field that references the parent object will allow us to quickly add parent information that we may want to reference quickly on a page layout or report.
Limitations and Other Notes
Since the Master Detail Relationship field is required to be filled out on the child record, the field must be on all of the page layouts. Standard objects like Account or Case can be the parent in the relationship, but not the child.
Importantly, each object can only be part of two total Master Detail relationships. This could be three “generations” where an object is the child of another object which in turn is the child of a third object. It could be one child with two parent objects.
Junction Objects
As discussed above, a Junction Object is a connection between two other Parent Objects. The Junction Object uses both of its two Master Detail relationships as the child. This creates the ability to have a many-to-many relationship which is so useful.
A great use case example of this is Job Seekers and Job Postings. As people looking for a job know, they may have to apply to MANY different positions before they land a role. It is not uncommon for someone to apply to multiple positions within the same company. Likewise, when a company posts a job, they expect multiple people to apply for it.
Without a junction object, we would only be able to associate on Job Seeker with a Job Posting. That is why we will use something in the middle – a Job Application – to connect the two. When an applicant (most likely a Contact in our Salesforce org), applies for a job, it will create an Application record that relates to the Contact and the Job Posting. Then if he or she puts their name in the hat for another role, it will create a second Application that relates to the same Contact, but now a different Job Posting.
Now as a company, we can look at our Job Seekers and each of their Job Applications. Or we can look at a Job Posting and see all of the Job Applications submitted. We can use roll-up summaries to see things like how many Applications a Contact has (count) or which was submitted first or last (Min, Max).
There is much more to discuss on relationships. Please take a look at Part 2 by clicking here.
