Master–detail relationships

The master–detail relationship links two objects in a strong way: children are close to their parent and are strongly related. So this type of relation is usually used to create a detail record.

When we create a new master–detail relationship, the first thing to select is the parent object.

Let's say we have a Case Detail custom object with diverse custom fields, and, as mentioned earlier, we want it to be a child of the Case object. Jump to Setup | Object Manager| Case Detail object| Fields & Relationships | New Field | Master-Detail relationship, and then select the parent object as Case on the first available picklist with a list of the available objects.

After the parent object type is selected, we'll define the relationship details:

Given the field name and child relationship name (which is used when SOQL-querying children records directly from the parent), we can define the minimum access level on the master record needed for the users to have complete access to the child object.

Select Read Only or Read-Write for the minimum access level on the parent object. In our scenario, let's leave this to Read-Write because we have decided that the Case Detail object data should follow the parent record's access.

In this scenario, sales reps who have read-only access to Case records will be able to read Case Detail objects, but will have no way to create, edit, or delete them.

The Child objects should usually strongly relate to their parents, since a few platform releases ago, you could reparent a child object. Using the Allow reparenting flag facilitates this possibility.

The last section of the master–detail configuration wizard is related to lookup filters. We can choose a filter based on the fields, namely the current object, parent object, current user, current user's profile, current user's role, or applying custom logic (conditions with custom and/or chaining).

A filter may be required or be optional. The user can receive a custom error message if the filter is mandatory or simply a suggestion filter. Users can easily remove filters and select whichever record they want.

Finally, a Lookup Window Text field guides the user as to the selection (we are explaining why this filter is in place, but it only works in Salesforce Classic) and the Active filter can be used to temporarily disable the filter.

This is what the final configuration looks like:

Click on the Next button at the bottom of the page to jump to the next step. Note that the Field-Level Security (FLS) for the new object's field defaults to Visible/Writable, and that the master–detail lookup is a required field by default (after all, you cannot have a child without a master record):

Click on Next to select the proper object page layout where the new field must be placed. Even now, the Case Detail page layout is mandatorily selected, as the field is required:

Click on Next again and select the Master object (Case) page layout in which the new Case Details- related list should be placed (this last step is only available for relationship field types):

Because we put in place a filter on the relationship that matches only support cases, selecting only the Case (Support) Layout makes perfect sense.

To test the relationship filters, let's create a new Custom Object tab from Setup | User Interface | Tabs | New in the Custom Object Tabs section and add it to the Service (standard__service) app:

Now, exit the setup and jump to the Service app, which looks as follows:

Click on the New button and create a new record. The only available field is the Case master–detail relationship. Select + New Case and create a new record with the unexpected record type (Sales Request):

Click on Save to save the case. The new record should now be related to the case detail record we are trying to create. Hit the Save button on the New Case Detail wizard to trigger the following error message:

If we select a Support Request record type in the previous step, then the case detail is saved as expected.

This is what you get in the lookup window in Classic mode (have a look at the initial Select a support request case message):

What's peculiar about master–detail relationships? The thing to note is that by deleting the master record, we are deleting its children as well (and when we undelete them—that is, restoring them from the bin—it will automatically undelete the children as well). However, if you delete one of the children first, and then delete the master record and then undelete it, the first deleted child will not be undeleted.

A child record inherits the master record's owner; that's why sharing rules and manual sharing is not available on child records. For the same reason, children inherit their master record's access level.

A custom object can have up to 2 master–detail relationships, up to 40 total relationship fields, and up to 5 active lookup filters (go to Setup | Object Manager | Custom Object | Object Limits for a full list). You can have a maximum of three master–detail levels and, within this hierarchy, the records cannot be referenced more than once. If it is a detail record on a given multilevel relationship, then it cannot be the master of another multilevel relationship.

For data skew limits, remember not to parent more than 10,000 child records to a master record.