Learning Objectives

After completing this unit, you will be able to:
  • Define the different types of object relationships and their typical use cases.
  • Create or modify a lookup relationship.
  • Create or modify a master-detail relationship.
  • Create or modify a many-to-many relationship.

Object Relationships

The Force.com database differs from relational databases in the way that record relationships are implemented. Instead of defining relationships through primary keys and foreign keys, the database uses relationship fields. A relationship field is a custom field on an object record that contains a link to another record.

Just as a personal relationship is a two-way association between two people, in terms of relational data, a relationship is a two-way association between two objects. Without relationships, you could build out as many custom objects as you can think of, but they'd have no way of linking to one another.

With relationships, you can display data about other related object records on a particular record's detail page. A relationship field stores the ID of the parent record in a relationship, as well as optionally providing user interface representations in both the parent and child records.

Relationships Allow Information about Other Object Records to be Displayed on a Record Detail Page Diagram of the relationship between the Position and Job Application custom objects in a record detail page

For example, suppose you’re building a recruiting app that contains custom objects for Position and Job Application. If you define a relationship between the Position and Job Application objects, each position record can have a related list of all the job applications for candidates who have applied for the position. Then a job application record can have a link to each position for which that candidate is applying.

Types of Object Relationships

There are two main types of relationship fields.

Lookup
This creates a relationship that links one object to another object. The relationship field allows you to navigate from records in one object to the related records in another object (both visually and programmatically). Lookup relationships can be used to create one-to-one and one-to-many relationships. When you define a lookup relationship, you have the option to include a lookup field on the page layouts for that object as well as create a related list on the associated object's page layouts.
For example, if you create a lookup relationship field on a Job Application object that references position records, many job application records can be related to a single position record. This will be reflected both with a new Position field on the job application record and with a new Job Applications related list on the position record. You can also put multiple lookup relationship fields on a single object, which means that the Job Application object can also point to a Candidate object.
Master-Detail
This creates a special type of relationship between two objects (the child, or detail) and another object (the parent, or master). This type of relationship closely links objects together such that the master record controls certain behaviors of the detail and subdetail record. In a master-detail relationship, the ownership and sharing of detail records are determined by the master record, and when you delete the master record, all of its detail records are automatically deleted along with it. Master-detail relationship fields are always required on detail records.
Master-detail relationships can be used whenever there is a tight binding between two objects. For example, say your recruiting app has a Review custom object that contains an interviewer's feedback on a job application. If you delete a job application record, you will probably want all of its review records deleted as well. In this case, you would create a master-detail relationship on the Review custom object with the Job Application object as the master object.
Note

Note

The master object in a master-detail relationship can also contain rollup summary fields. These fields store values aggregated from the child records in the relationship. For example, you can use these fields to count the number of child records, sum values in field of a child record, or determine the maximum/minimum of a field in a filtered set of child record.

Differences Between Lookup and Master-Detail Relationships

There are fundamental differences between the two types of relationships in areas such as data deletion, sharing, and required fields in page layouts.

Master-detail relationships are typically used when there is a direct dependency between the two objects. These relationships have the following unique features.
  • You can’t create a detail record without a master record.
  • When you delete a master record, all its detail records are automatically deleted.
  • The detail record inherits sharing rules from the master record.
  • The number of master-detail relationships you can use are limited, depending on your edition and license.
  • You can’t set profile object permissions for a detail record. The detail record inherits permissions from the master record.
  • Master-detail relationships are automatically included in report record types.
Lookup relationships are appropriate when a relationship between two objects is required in some cases, but not always. Typical scenarios for lookup relationships are:
  • To reference commonly shared data, such as reference data.
  • To relate multiple parent records to the child record.
  • To link two objects together when you don't want the behavior of the master-detail relationship, such as sharing rules, profile permissions and cascade delete.
  • If the detail object has its own tab, then you probably want to use a lookup, and not a master-detail, relationship.

You can convert a master-detail relationship to a lookup relationship as long as no roll-up summary fields exist on the master object. You can convert a lookup relationship to a master-detail relationship, but only if the lookup field in all records contains a value.

Create Objects to Relate

Before going further, create some custom objects to practice establishing relationships. You need custom objects called Candidate, Position, Job Application, and Review. For a reminder of how to create the Candidate object, go to the Creating Custom Objects and Fields unit. Then create the Position, Job Application, and Review objects.

Here’s how to create each object with its new tab.

  1. From Setup, enter Objects in the Quick Find box, then select Objects under Create.
  2. Click New Custom Object.
  3. Enter a label, plural label, object name, and description.
  4. To set up a tab for the object, under Object Creation Options, select Launch New Custom Tab Wizard.
  5. Click Save.
  6. On the New Custom Object Tab page, select a tab style.
  7. For the rest of the wizard, keep the defaults and then click Save.

Create a Lookup Relationship

Suppose you want to associate a hiring manager with a position by putting a lookup relationship field on the Position object. The lookup field allows users to select the hiring manager for the position by selecting from all the users of the Recruiting app.

For example, to assign someone as the hiring manager for the Technical Writer position, recruiters can click the lookup icon (Lookup icon) next to the lookup relationship field. The hiring manager’s name then appears on the Position detail page.

Let’s say you want to put a Hiring Manager field on the Position object. Create a many-to-one relationship between the Position object and the standard User object that comes with every org. This relationship reflects that a hiring manager can be responsible for several positions at a time.

To create the lookup relationship fields:

  1. From Setup, enter Objects in the Quick Find box, then select Objects.
  2. Click Position.
  3. In the Custom Fields & Relationships related list, click New.
  4. Select Lookup Relationship, and click Next.
  5. In the Related To drop-down list, choose User, and click Next.
    Note

    Note

    User is a standard object that comes with all organizations on the platform. It contains information about everyone who uses the app in your organization.

  6. In the Field Label text box, enter Hiring Manager. Once you move your cursor, the Field Name text box is automatically populated with Hiring_Manager.
  7. Click Next.
  8. Accept the defaults in the remaining two steps of the wizard.
  9. Click Save.

Beyond the Basics

You can also create a hierarchical relationship between objects. A hierarchical lookup relationship is available only for the user object. It lets you use a lookup field to associate one user with another who’s not automatically linked to the first user. For example, create a custom hierarchical relationship field to store each user's direct manager.

Create a Master-Detail Relationship

Let’s continue with the example of the recruiting app. Interviewers, recruiters, and hiring managers create reviews so they can record their comments about each candidate's job application, and rate the candidate's suitability for the position. They also read the reviews posted by other people. To enable our users to do these tasks, we'll create a custom Review object and relate it to the Job Application object.

The Review object has a many-to-one relationship with the Job Application object because one job application can have one or more reviews associated with it. A related list on the job application record shows the associated reviews, representing the “many” side of the relationship.

Review Has a Many-to-One Relationship with Job Application A diagram of the one-to-many relationship between reviews and a job application

However, instead of creating this relationship with a lookup relationship field, you can use a master-detail relationship field. A master-detail relationship field makes sense in this case because reviews lose their meaning when taken out of the context of a job application. Accordingly, you want your app to automatically delete reviews when you delete a job application to which they're related.

To create the master-detail relationship field to relate the Review object with the Job Application object:

  1. From Setup, enter Objects in the Quick Find box, then select Objects.
  2. Click Review.
  3. In the Custom Fields & Relationships related list, click New.
  4. Select Master-Detail Relationship, and click Next.
  5. In the Related To drop-down list, choose Job Application, and click Next.
  6. Click in the Field Name text box and enter the field name Job_Application.
  7. Select the Read/Write radio button.
  8. Check Child records can be reparented to other parent records after they are created if you want to be able to change the relationship field’s value. If you leave this box unchecked, you can’t change the value in the future.
  9. Click Next.
  10. Accept the defaults in the remaining three steps of the wizard.
  11. Click Save.

This sharing setting prevents people from creating, editing, or deleting a review unless they can also create, edit, or delete the associated job application. We'll learn about sharing and security in the next chapter.

Your master-detail relationship is complete!

Beyond the Basics

You can also create a master-detail relationship with multiple levels. With multilevel master-detail relationships, create reports that roll up data from all levels of the data model, and trigger cascading deletes when a master record is deleted. For example, you want a candidate’s applications and review records to be deleted when a hiring manager deletes a candidate. Create a new master-detail relationship field that relates the Job Application object with the Candidate object. The Review and Job Application objects are already related to each other in a master-detail relationship, so you’ve built a multilevel relationship where Candidate is the master, Job Application is the detail, and Review is the subdetail.

Create a Many-to-Many Relationship

You can use master-detail relationships to model many-to-many relationships between any two objects. A many-to-many relationship allows each record of one object to be linked to multiple records for another object, and vice versa. For example, suppose your recruiting app has a custom object called Website that stores information about various employment websites. You want to track which open positions are posted to those sites. Use a many-to-many relationship because:
  • One position could be posted on many employment websites.
  • One employment website could list many positions.

Instead of creating a relationship field on the Position object that directly links to the Website object, we can link them using a junction object. A junction object is a custom object with two master-detail relationships, and is the key to making a many-to-many relationship. To create a many-to-many relationship, you first create the junction object, then create the two master-detail relationships for it.

Let's look at a typical scenario in the recruiting app. There are open positions for a Project Manager and a Sr. Developer. The Project Manager position is only posted on Monster.com, but the Sr. Developer position is harder to fill, so it's posted on both Monster.com and Dice. Every time a position is posted, a job posting record tracks the post. As you can see in the following diagram, one position can be posted many times, and both positions can be posted to the same employment website. In relational database terms, each job posting record is a row in the Job Posting table. Each row consists of a foreign key to a position record, and a foreign key to a website record.

So, to define a many-to-many relationship between the Position and Employment Website objects, you’d create a Job Posting object with the following fields:
  • A Position master-detail relationship
  • A Website master-detail relationship
Using a Job Posting Object to Create a Many-to-Many Relationship Between Positions and Employment Websites A diagram of the many-to-many relationship between Positions and Employment Websites

To handle this scenario, you can create a junction object called Job Posting. A Job Posting record represents a posting about a single position on a single employment website. In essence, the Job Posting object has many-to-one relationships with both the Position and Website objects. Through those many-to-one relationships, the Job Posting object also creates a many-to-many relationship between the Position and Website objects.

Create the Junction Object

  1. From Setup, enter Objects in the Quick Find box, then select Objects.
  2. Click New Custom Object.
  3. In the custom object wizard, consider these tips specifically for junction objects:
    • Name the object with a label that indicates its purpose, such as JobPosting.
    • For the Record Name field, we recommend using the auto-number data type.
    • Leave the “Launch New Custom Tab Wizard after saving this custom object” box unchecked before clicking Save. Junction objects don’t need tabs.

Create the Two Master-Detail Relationships

  1. On the junction object, create the first master-detail relationship field. In the custom field wizard:
    1. Choose Master-Detail Relationship as the field type.
    2. Select one of the objects to relate to your junction object. For example, select Position.

      The first master-detail relationship you create on your junction object becomes the primary relationship.

    3. Give your master-detail relationship a name.
    4. Select a Sharing Setting option. For master-detail relationship fields, the Sharing Setting attribute determines what access users must have to a master record to create, edit, or delete its associated detail records.
    5. Optionally, add your new field to the page layout.
    6. For the Related List Label that displays on the page layout of the master object, don’t accept the default. Change the label to the name of the other master object in your many-to-many relationship. For example, change it to Websites so users see a Websites related list on the Position detail page.
      Note

      Note

      We haven’t created a custom object called Website as part of this module. To try out this step, create a custom Website object using the steps from the Creating Custom Objects and Fields unit.

  2. On the junction object, create the second master-detail relationship. In the custom field wizard:
    1. Choose Master-Detail Relationship as the field type.
    2. Select the other desired master object to relate to your junction object. For example, select Website.

      The second master-detail relationship you create on your junction object becomes the secondary relationship. If you delete the primary master-detail relationship or convert it to a lookup relationship, the secondary master object becomes primary.

    3. Select a Sharing Setting option.
    4. For the Related List Label that displays on the page layout of the master object, don’t accept the default. Change the label to use the name of the other master object in your many-to-many relationship. For example, change it to Positions so users see a Positions related list on the Website detail page.

For a many-to-many relationship, each master object record displays a related list of the associated junction object records. For a seamless user experience, change the name of the junction object related list on the master object page layouts to the other master object’s name. For example, change the JobPosting related list to Positions on the websites page layout and to Websites on the positions page layout. You can further customize these related lists to display fields from the other master object.

Tell Me More...

You can change the parent record for a child record in a master-detail relationship. To enable this option, select the Allow reparenting option in the master-detail relationship field definition. By default, you cannot “reparent” records in master-detail relationship.

A lookup relationship field is optional but you have the option to make it required. When a lookup field is optional, you can specify one of three actions to take place on dependent lookup fields when someone deletes a referenced lookup record.
  • Clear the value of this field: This is the default option. Setting a lookup field to null is appropriate when the field does not have to contain a value.
  • Don’t allow deletion of the lookup record that’s part of a lookup relationship: This option restricts the deletion of a lookup record that has dependencies, such as a workflow rule built on the relationship.
  • Delete this record also: This option cascades the deletion of a referenced lookup record to dependent records. It is available only for lookup fields in a custom object; however, the lookup field can reference either a standard or custom object. Choose this option for tightly-coupled record relationships when you want to completely delete related data in one operation
Share Time Estimate

Having trouble with your challenge verification?

Here are some tips:

  1. Check for typos (hey, it happens)
  2. Try using a new Developer Edition (existing customizations can interfere with the validation)