A Master/detail relationship closely links two objects together, so much so that certain behavior of the child record is affected. This includes sharing, whereaccess to the Master (or parent) record gives access to the detail (or child) record. Master/detail relationships also support roll-up summaries.
When Master records are deleted, all child records are deleted. However, un-deleting a Master record restores all child records. When a detail record is deleted, it is moved to the recycle bin. If a detail record is deleted and subsequently the Master record is deleted, the detail record cannot be restored as it no longer has a Master record to associate to.
Lookup and master-detail relationship types are both one-to-many (where many records can be linked to one other record, for example an account having multiple contacts). Many-to-many relationships (for example, linking a case to more than one custom bug record, and multiple custom bug records to the same case) are represented using two master/detail relationships connected via a junction object (a custom object with two master-detail relationships). Many-to-many relationships can only therefore be used to connect one object to a different object. In our cases and bugs example, we have the standard case object with a master-detail relationship to our BugCaseAssociation junction object, and a custom bug object with a master-detail relationship to our BugCaseAssociation junction object. This can be represented pictorially:
Figure 2.7 – Representing a many-to-many relationship with two master-detail relationships
With master/detail and many-to-many relationships now covered, let’s look at the other relationship types.
A lookup relationship links two objects together, except that sharing is not affected (and therefore the child object can have separate sharing, unlike that of master-detail relationships where sharing is affected), and roll-up summaries aren’t supported. Lookup relationships support linking two objects together, but that can include looking up to records of the same object type (think account hierarchies where an account record can have a parent account record to represent the hierarchy of a company group structure). An object with a lookup relationship to itself is called a self-relationship. The user object should instead use a hierarchy relationship (see the Hierarchical section) when looking up to itself.
When linking external object records to a Salesforce standard or custom object, and the external object is the parent object, then an external lookup relationship is used. The standard external ID field on the parent external object is matched against the values of the child object’s external lookup relationship field.
When linking external object records to a parent object whose data exists in Salesforce as either a standard or custom object, an indirect lookup relationship should be used to associate the records. When creating an indirect lookup, you specify which field in the parent object and which field on the external object to match against and therefore associate records. A custom, unique, external ID field is selected on the parent object to match against the child external object’s indirect lookup field, which comes from the external data source.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
