Lookup or Master-Detail? Choosing the Right Salesforce Relationship

Lookup vs Master-Detail: How to Choose the Relationship Type on Real Examples 

Introduction

In Salesforce, objects rarely exist in complete isolation from one another. When working on real-world projects, you’ll need to link records - for example, you’ll need to link projects and tasks, orders and their line items, or customers and related data. To perform these simple yet very important tasks, you need to understand what types of relationships exist, as well as how and when they are used. The two relationship types you'll use most often are Lookup and Master-Detail.

At first glance, they do the same job: they point a child record to its parent. Under the hood, though, they behave very differently, and that difference matters a lot when you design a data model. The choice of relationship type affects record independence, access control, deletion behavior, and automation capabilities.

Now we’ll look at practical examples of relationships between projects and tasks, as well as between orders and their line items. Based on these examples, we’ll examine when each type of relationship is appropriate, what consequences our choice will have, and what to consider before creating a relationship in Salesforce.

Lookup vs. Master-Detail: Key Differences

Before getting to the examples, let's go through how each relationship type works. Both link records together, but they handle dependency, access, and deletion in different ways. It's worth sorting this out at the design stage: changing the relationship type later, once the org is full of data, is much harder.

Lookup Relationship

A Lookup Relationship links a record of one object to a record of another object via a Lookup field. This relationship provides an independent model between the linked records. 

But you must understand that, although this relationship ensures that one record is independent of another, the result will still depend on the field settings, the security model, and the object's characteristics.

Key Features

• Weak relationship: The records are not strictly linked to one another, which means they can exist independently.
• Optional relationship: The lookup field can be left empty by default, unless you configure it as required.
• Independent ownership: Each record keeps its own owner and sharing settings.
• Flexible deletion behavior: When the parent is deleted, Salesforce either clears the lookup field or blocks the deletion, depending on how the field is set up. Cascade deletion for Lookup relationships is available only for custom lookup fields and must be enabled by Salesforce Support. It is not available as a standard option in the field settings.
• Independent Management: Related records can be created, edited, and managed separately.
• No Standard Roll-Up Summary: For custom objects, Roll-Up Summary fields require a Master-Detail relationship (a few standard relationships, such as Account–Opportunity, are exceptions).

Advantages

• Provides the greatest possible flexibility when linking records.
• Allows for the use of optional relationships in many scenarios.
• Supports various access control models.
• Ideal for situations where records should not depend on one another.
• Allows you to avoid the limitations that arise when using a master-detail relationship.

Example

Let’s assume that a company uses two objects to manage its tasks: Project and Project Task.

A Project Task record may contain a Project__c field that references a specific project. Still, a task usually has its own owner and sharing settings, and the team works with it separately from the project.

That's why Lookup fits here: the two objects are connected, but a task shouldn't take its owner or access from the project.

Master-Detail Relationship

A Master-Detail Relationship establishes a close connection between two objects. In this relationship, one object always acts as the Master, and the other as the Detail. The Detail will always depend on the Master and inherit important properties at the record level.

This type of relationship is ideal for situations where a child record cannot exist as a standalone record but must be part of a parent record.

Key Features

• Strong Relationship: A detail record depends on the master record and cannot exist without it.
• Mandatory Relationship: A Detail record is always linked to the Master record.
• Ownership Inheritance: A Detail record cannot have an independent owner.
• Record-Level Access Inheritance: Access to Detail records is controlled solely through the Master record.
• Cascading Deletion: Deleting a Master record always deletes the associated Detail records.
• Roll-Up Summary Fields: A Master record can calculate values based on associated Detail records using the COUNT, SUM, MIN, and MAX functions.
• Stricter Configuration Rules: Modifying or transforming a relationship may require additional conditions to be met and may affect the data model.

Advantages

• Creates a strict parent-child structure.
• Simplifies the management of detail records through the master record.
• Supports standard roll-up summary fields.
• Simplifies ownership and access management at the record level.
• Ensures a close relationship between child and parent records.
• Is suitable for cases where a detailed record has no meaning outside of a master record.

Additional Limitations

• A standard object cannot be on the detail side of a custom Master-Detail relationship.
• A custom object can have a maximum of two Master-Detail relationships.

Recycle Bin Behavior

Deleted detail records don't disappear for good right away: they go to the Recycle Bin together with the master. If you restore the master, Salesforce brings its detail records back too, still linked to it.

For example, deleting a Customer Order also deletes its Order Lines, and restoring the order brings them back.

Example

Let's take a look at how a Master-Detail Relationship can be used to organize orders and their line items. Assume that a company uses two objects: Customer Order and Order Line. 

When a customer selects products and places an order, a Customer Order record is created in Salesforce. It contains general information about the order, such as customer details, the order date, and the total amount.

Every item that a customer adds to their order is stored as a separate Order Line record. This record contains information about the item, such as the price, quantity, or name, and each item is linked to a specific order and depends on it.

A Master-Detail Relationship is the best choice here because an Order Line cannot exist without a Customer Order.

Summary Comparison of Lookup and Master-Detail Relationships 

Now that we have examined the characteristics and practical applications of both relationship types, we can identify their main differences.

Converting Relationships

Salesforce allows certain Lookup and Master-Detail relationships to be converted from one type to another. However, specific conditions must be met before the conversion can be performed.

Converting a Lookup Relationship to a Master-Detail Relationship

This only works if every child record already has a parent, meaning the lookup field is filled in on every record. Check this before converting: if even one record has an empty field, Salesforce won't let you make the change.

Converting a Master-Detail Relationship to a Lookup Relationship

This is only possible if the master object has no roll-up summary fields based on this relationship, so delete them first.

Relationship conversion can affect ownership, access settings, and other aspects of the data model. Review the existing configuration before making changes.

Practical Example: Creating and Comparing Lookup and Master-Detail Relationships 

To help you better understand the difference between a Lookup Relationship and a Master-Detail Relationship, let's look at two practical examples in Salesforce. In each example, we'll create a custom object, set up a relationship, and see how it works.

Example 1 - Lookup Relationship

Let's say you want to create your own small task tracker to manage tasks and projects.

• Project - an object that stores information about projects.
• Project Task - an object that stores information about individual tasks.
• A project task may be associated with a specific project, but it does not necessarily have to depend on it.

To implement this scenario, we will create a lookup relationship from the Project Task object to the Project object.

Step 1. Creating a Project Object

1. Open Setup in Salesforce.
2. Go to the Object Manager.
3. Click Create → Custom Object.
4. Fill in the fields
5. Click Save.
6. If necessary, finish configuring the Custom Tab Wizard.

Step 2. Creating a Project Task Object

Repeat the same steps:

Setup → Object Manager → Create → Custom Object 

Fill in the fields:

Note: Label and Object Name are separate fields when creating a custom object. The Label is the name users see in the Salesforce interface, while the Object Name is used as the basis for the API Name. The Object Name cannot contain spaces; for example, the Object Name Project_Task produces an API Name such as Project_Task__c.

Note: Custom object names such as Project Task, Customer Order, and Order Line are used to distinguish them from standard Salesforce objects with similar names. 

Step 3. Creating a Lookup Relationship

1. Open Object Manager → Project Task.
2. Go to Fields & Relationships.
3. Click New.
4. Select Lookup Relationship.
5. Click Next.
6. In the Related To field, select Project.
7. Continue configuring the field and save it.

As a result, the Project Task object will have a field that references the Project record. 

Step 4. Creating Test Records

Create a single Project record:

Create a single Project Task record:

Save the record.

The Project Task is now linked to the Project via a lookup relationship.

Step 5. Checking the Lookup Relationship 

1. Open the Project Task record.
2. Locate the Project lookup field.
3. Verify that it references the Website Redesign Project record.

The Project Task is linked to the Project, but the Lookup Relationship does not make the Project Task a dependent detail record.

Step 6. Testing Deletion Behavior

This step demonstrates the difference between Lookup and Master-Detail relationships in practice.

1. Open the Website Redesign Project record.
2. Delete the Project record.
3. If necessary, confirm the deletion.
4. Open the Update Homepage Layout Project Task record.
5. Verify that the Project Task record still exists.
6. Check the Project lookup field.

Expected result:

The Project Task record still exists, while the Project lookup field is cleared when the referenced Project is deleted under the standard clear-lookup deletion behavior.

Result

In this example, we created a Lookup Relationship between Project Task and Project. A Project Task record can reference a Project, but the relationship itself does not make the Project Task a dependent detail record. 

We also tested the deletion behavior. The Project Task record remained available after the Project record was deleted, and its Project lookup field was cleared under the applicable configuration. 

This type of relationship may be suitable for scenarios where tasks need to be managed relatively independently, and the connection to the project is optional.

Example 2 - Master-Detail Relationship

Let's say you want to track customer orders and the products included in each order.

• Customer Order - a custom object that stores information about an order.
• Order Line - a custom object that represents a single line item in an order.
• An Order Line must be associated with a specific Customer Order.

In this case, the master-detail relationship will meet the requirements, since the line item is part of the order.

Step 1. Creating a Customer Order Object 

Repeat the same steps:

Setup → Object Manager → Create → Custom Object 

Fill in the fields:

After that, save the object.

Step 2. Creating an Order Line Object 

Repeat the same steps:

Setup → Object Manager → Create → Custom Object 

Fill in the fields:

Click Save.

The Auto Number Record Name provides a consistent identifier for each Order Line record. 

Step 3. Creating Additional Fields

To display product lines, let's create two additional fields on the Order Line object.

Quantity

Unit Price

These fields will be used later to calculate the Line Total for each Order Line. 

Step 4. Creating a Master-Detail Relationship

1. Open Object Manager → Order Line.
2. Go to Fields & Relationships.
3. Click New.
4. Select Master-Detail Relationship.
5. Click Next.
6. In the Related To field, select Customer Order.
7. Continue configuring and save the field.

In this case, the Customer Order will act as the Master, and the Order Line will act as the Detail.

Additional Relationship Settings 

When available in the Master-Detail field configuration, review the following options: 

Allow Reparenting is disabled by default. Enable it only when the business requirements allow detail records to be reassigned to a different master record.

The Sharing Setting affects the access requirements for detail records and should be configured according to the required security model.

Step 5. Creating a Formula Field: Line Total 

We will use the Quantity and Unit Price fields to calculate the total value of each Order Line. 

1. Open Object Manager → Order Line.
2. Go to Fields & Relationships.
3. Click New.
4. Select Formula.
5. Click Next.
6. Enter the field label: Line Total.
7. Select the return type: Currency.
8. Enter the formula using the field picker: Quantity × Unit Price

Example formula: Quantity__c * Unit_Price__c

The exact API names may differ depending on the field configuration. Use the Formula Editor field picker to select the correct fields. 

Step 6. Creating Test Records

Create one Customer Order record.

Then create two Order Line records associated with the same Customer Order. 

Save both records.

Step 7. Checking the Master-Detail Relationship

Open the Customer Order you created and verify that the associated Order Lines appear in the corresponding related list. 

Step 8. Creating a Roll-Up Summary Field

One of the features of a master-detail relationship is the ability to create a roll-up summary field on the master object. This field allows you to automatically aggregate data from the associated detail records.

1. Go to Setup → Object Manager.
2. Open the Customer Order object.
3. Go to Fields & Relationships.
4. Click New.
5. Select the Roll-Up Summary field type.
6. Click Next.

Fill in the settings as follows:

Now let's check the result:

1. Open the sample Customer Order. 
2. Make sure that two Order Line records are associated with it. 
3. Locate the Total Order Lines field.
4. Verify that its value is 2.

Step 9. Creating a Roll-Up Summary Field: Order Total 

In addition to counting the number of Order Line records, we can calculate the total value of all order lines associated with an order. 

1. Go to Setup → Object Manager.
2. Open the Customer Order object.
3. Go to Fields & Relationships.
4. Click New.
5. Select Roll-Up Summary.
6. Click Next.

Fill in the settings as follows:

Step 10. Checking the Order Total 

Now let's check the result:

1. Open the sample Customer Order.
2. Verify that two Order Line records are associated with it.
3. Locate the Order Total field.
4. Verify that its value is 1250.

Note: The displayed currency format depends on the currency and locale settings of the Salesforce org. For example, the value may appear as 1,250.00 or 1 250,00 zł, while the calculated numeric total remains 1250.

The total is calculated as follows:

• Order Line 1: 1 × 1200 = 1200 
• Order Line 2: 2 × 25 = 50 
• Order Total: 1200 + 50 = 1250 

Step 11. Testing Cascading Deletion 

To test the deletion, use only test records:

1. Open a test Customer Order. 
2. Check the associated Order Lines.
3. Delete the Customer Order. 
4. Verify that the associated detail records have been deleted.

The Master-Detail Relationship supports the cascading deletion of associated detail records when a master record is deleted.

Result

In this example, we created a Master-Detail Relationship between Customer Order and Order Line. An Order Line record depends on a Customer Order record, and when the parent record is deleted, the associated child records are also deleted. 

We also created two Roll-Up Summary fields on the Customer Order object. The Total Order Lines field uses the COUNT calculation to count the associated Order Line records, while the Order Total field uses the SUM calculation to calculate the total value of the order based on the Line Total field. Remember that for custom objects, Roll-Up Summary fields require a Master-Detail relationship.

This type of relationship may be suitable for scenarios in which the parent must manage the child elements, and the child elements cannot exist without the parent.

How to Choose the Right Relationship Type?

We’ve reviewed two relationship types, but now the question arises: how do we choose which one to use? There's no universal answer: the right choice depends on your requirements. The following guidelines can help you decide.

Choose a Lookup Relationship if:

• The record must remain independent
• The relationship between the objects is optional
• Records need their own owners and access settings
• Deleting one record should not delete others
• You need flexibility in managing objects

Choose a Master-Detail Relationship if:

• The detail record depends on the master record.
• The child record must be part of the parent structure.
• Ownership and access must be inherited at the record level.
• Standard Roll-Up Summary Fields are required.
• Deleting the Master must result in the deletion of associated Detail records

Conclusion

We’ve gone over the two main types of relationships - Master-Detail Relationship and Lookup Relationship - and examined their key features and examples of their use.

As we’ve seen, the choice of relationship type ultimately depends on the requirements of your task. However, it’s important to remember that a Lookup Relationship is suitable when records need to remain independent and require greater flexibility in management. Meanwhile, a Master-Detail Relationship is used when a child record must depend on a parent record and inherit its properties.

Thus, making the right choice will allow you to create a more suitable data model, but before creating a relationship, it’s best to analyze the logic, requirements, and existing dependencies between objects.