Use the same account next time to pick up where you left off.
|Production Salesforce account||Developer Edition or Admin Playground|
|Do I need to be a Salesforce customer?||Yes||No (It's free!)|
|Can I use it to create my Trailhead profile and store my badges?||Yes||Yes|
|Can I use it to complete Trailhead challenges?||No (except for multiple choices quizzes)||Yes|
|Can I keep my Trailhead badges if I leave my company?||No||Yes (use a personal email address)|
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.
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.
There are two main types of relationship fields.
There are fundamental differences between the two types of relationships in areas such as data deletion, sharing, and required fields in page layouts.
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.
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.
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 () 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:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.