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.

Think about adding a Case Detail custom object that stores multiple case details, such as multiple products, addresses, or repeated business data (for example, energy readings coming from all contacts’ smart home devices) related to the same service request (Case record). Those details have no meaning without the original Case; that’s why we choose a master–detail relationship to design this specific model.

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

Note that a master–detail field cannot be created on a standard object. This is a platform limitation that any admin should be aware of.

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.

You cannot create a master–detail field on an object that is related to the same object type.

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

Master–detail relationship options

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:

Master–detail filter configuration