Data relationships between objects in Salesforce can be a tricky topic to get your head around. You may be faced with a business scenario that requires creating a custom object, and then the next decision is which relationship types you should use to extend your Salesforce data model.
Relationship types have been on my mind recently. Not so long ago, I answered a question on the Salesforce Trailblazer Community whereby the poster was asking about the best approach to record customer insurance policies. The initial idea they had was to add multiple fields on a record to track each policy. I instead of creating duplicate fields with the same purpose (not scalable) I suggested they create a custom object to form a one-to-many relationship. So what better opportunity for me to explain Salesforce relationship types and how they can be utilised!
Relationship Type 1: Lookups
A Lookup is a loosely coupled relationship, allowing you to connect one object to another in a one-to-many fashion.
In this example, you can see that an Asset may be involved with a number of cases. In this scenario, if the case is deleted, the Asset will remain and visa versa.
Relationship Type 2: Master-Detail
A master-detail relationship is a strongly coupled relationship, meaning if the parent is deleted, so are the child records. This is a good thing and can be incredibly helpful.
This relationship seems to scare people, but it shouldn’t!
Master-detail also allows the parent record to control child record attributes such as sharing and visibility. Whichever security setting you chose for the parent record, the child record inherits.
In this example, you have a list of rooms in which employees can book out for meetings. However, should the room be deleted, what use would the meetings be? None, so they go too. However, when creating a master-detail relationship, you can check a box to allow reparenting… so you could be kind and allow them to select a new room!
The sweet spot with Master-detail relationships is that you can create rollup summary fields! Do take note, a single object can have a maximum of 2 master-detail relationships.
Lookups vs. Master-Detail Relationships
|Lookup relationship||Master-detail relationship|
|Loosely coupled.||Strongly coupled.|
|Roll-up summary field not available.||Roll-up summary field is available..|
|Parent record is not required when creating a child record.||Parent record is required in order to save a child record.|
|Lookup fields are not required on the page layout of the detail record but if you make them a required field, it is advised!||Master-detail field is always required on the page layout of the detail record (because of the point above).|
|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.||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 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.|
Multiple Lookups on the Same Object?
Let’s say, for example, you have a Campaign. This campaign is part of a bigger campaign. You can use a lookup field from campaign to… campaign! Why? This would be a great situation to show how multiple child campaigns relate to the main parent campaign (known as a Campaign Hierarchy).
Junction Objects: We All Want To Be Important!
Say you have a situation where it is required you have many of one record related to many of another. Duplicating that lookup field a number of times on each object is not best practice and will get very messy. This is where we should leverage Junction Objects.
In the image below, we see that a session can have multiple speakers but also speakers can present at multiple sessions. A perfect place to add that junction object of ‘Session Speaker’ inbetween to handle this relationship!
External Objects – Lookups Beyond the Org!
There are are two more types of Lookups for working with external objects we should cover briefly:
- indirect lookup relationships: allow a relationship to be formed between a Salesforce 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.
We’ve come to the end of this guide! Is your head spinning? Although these relationships should have the status ‘it’s complicated’, hopefully you understand the options available for relating objects to each other Salesforce and when to use each.