# Lookups and relationships > Relate custom objects to each other and to Rippling objects. ## What is a lookup field? Lookup fields let you establish relationships in your data. You can then use those relationships to link information together in Rippling. - Populate the lookup field with the value from the other object. - Display a list of records from one object on another one as a related list. - Display fields from one object on another object as related fields. - Calculate new values using RQL by traversing related objects. * * * ## Objects you can use in lookups You can create a lookup between any two custom objects. You can also use a lookup field to look up the following Rippling objects: - Employee - Department - Team - Work location - Device - Application (Recruiting) - Job requisition (Recruiting) * * * ## How do I know if I need a lookup field? When you add custom objects to Rippling, there may be overlap where the fields intersect. For example, the client might appear on both a Project object and a Client object. To link these two objects, add a lookup field on the project that references the associated client. You might also want to use fields that you know already exist in Rippling. For example, a project manager and an account manager are people who exist in Rippling, so you can add a lookup to the Employee object on each object to tie it to the associated person. > **Note:** > There is a limited set of Rippling objects you can use in lookups, as outlined above. If there is a Rippling native field you want to use that isn’t available as a lookup, consider using a [simple formula field](https://developer.rippling.com/documentation/rippling-platform/custom-objects/fields#formula-fields) instead. More examples: - Tie a **requester** to a **help desk request**. Put a lookup field on the help desk request object to look up the requesting employee. - Associate **invoice line items** with an **invoice**. Put a lookup field on the line item object to look up the invoice to which it belongs. - Capture a **class signup** and link it to the **class** for which the attendee registered. Put a lookup field on the signup to look up the class. * * * ## Understanding data relationships The exact location where you create the lookup is important as it determines what you’ll be able to do with your data later. To understand where you should add a lookup field, you need to identify the type of relationship between the two objects. There are three types of data relationships: - One-to-many / many-to-one - Many-to-many - One-to-one (this is not common) ### How to identify the type of relationship For any two objects where a relationship exists, say the following sentences out loud. Based on your answers, you’ll know which type of relationship applies. - “Each A can have \[one / many\] B.” - “Each B can have \[one / many\] A.” For example: - “Each project can have **one** client.” - “Each client can have **many** projects.” Because you said “one” and “many,” there is a **one-to-many** relationship between projects and clients. More examples: - Each employee can have **many** licenses. Each license is for **one** employee. This means there is a many-to-one relationship. - Each student can be registered for **many** classes. Each class can have **many** students. This means there is a many-to-many relationship. - Each applicant can apply to **many** jobs. Each job can have **many** applicants. This means there is a many-to-many relationship. > **Note:** > If there is ever a case where the response is one OR many, assume many. This ensures you’ll be set up to handle the more complex relationship when you encounter it. ### Where to add lookup fields based on relationship type #### One-to-many To establish a one-to-many relationship, put a lookup field on the **many** to look up the **one**. For example, there is a one-to-many relationship between clients and projects, with clients being the one and projects being the many. Add a lookup field on the Project object to look up the Client object. #### Many-to-many To establish a many-to-many relationship: - Add a third object, also known as a **join object**. - Add lookup fields on the join object to look up the two other objects. For example, there is a many-to-many relationship between students and classes. Add a third object called class registrations, then add two lookup fields on the class registrations object: - Student object lookup - Class object lookup Creating a join object lets you minimize and consolidate the number of lookup fields you need to create. It also lets you collect additional information relevant to each registration event. For example, in the class registrations object, you may want to collect a date/time of registration, the amount that was paid, and whether the student requested any special accommodations. #### One-to-one One-to-one relationships are relatively rare. Typically, rather than creating a one-to-one relationship between two objects, you can simply add all of the necessary fields to a single object. However, if you want to be able to reassign something from one object to another in the future, having it set up as a one-to-one relationship will come in handy. That way, you can simply reassign the object rather than moving all of the data from one object to another. For example, there is a one-to-one relationship between an employee and their job. Each employee can only have **one** job, and the job can only belong to **one** employee. However, you may need to reassign the job at some point in the future. In this case, it makes sense to create a one-to-one relationship. To create a one-to-one relationship between custom objects: 1. Create a lookup field on either object to look up the other one. 2. Add a basic text field on the object that has the lookup field and indicate that it can’t have duplicate values. 3. Create a [rule](https://developer.rippling.com/documentation/rippling-platform/custom-objects/rules-and-validations) that copies the value from the lookup field into the text field whenever records are created or updated. If someone attempts to create a new record that looks up the same value as an existing record, the new record will automatically be assigned the same name as the existing record. And because duplicate values are not allowed in the name field, the save of the new record will fail. You must have admin permission for the objects. * * * ## Parent/child relationships When you add a lookup field, you also have the option to establish a parent/child relationship between the objects. Typically, the child object will be the many in a one-to-many relationship. For example: - If you have one object to capture invoices and another object to capture line items appearing on that invoice, the Invoice object would be the parent and the Line item object would be the child. - If you have one object that lists your training classes and another that lists registrations for each class, the Class object would be the parent and the Registration object would be the child. When you establish a parent/child relationship between two objects, the objects receive the following capabilities: - **Add summary fields.** You can add a summary field on the parent object to calculate a sum, count, minimum, or maximum value of the child records. For example, you could use a summary field to calculate the total expenses for a project. For more information, see [Summary fields](https://developer.rippling.com/documentation/rippling-platform/custom-objects/fields#summary-fields). - **Automatically delete child records.** Child records will be automatically deleted when the associated parent record is deleted. For example, when you delete an invoice, the associated invoice line items will be deleted automatically. - **(Optional) Automatically inherit ownership from the parent.** You can optionally require child records to inherit the same owner as the parent object. ### Owner fields in parent/child relationships When you enable a parent/child relationship, you’ll choose whether you want to require child records to inherit their owners from their parent record so they are the same. You might want the owner in both objects to be **the same** to ensure the permissions for the child records are the same as for the parent. Also, in cases where multiple people are adding child records, this will ensure the owner is set correctly in child records. You might want the owner to be **different** if you want to give different permissions on the two objects. For example, if you want to let people see their own class registrations but not see who else has registered, you would set the owner of the class registration to the registrant and the owner of the class to be the instructor. You can then give registrants permission to see only their own registrations while allowing the instructor to see all registrations. To force the child records to have the same owner as the parent record, enable the **Parent-Owner Inheritance** setting. > **Note:** > When this setting is enabled, the person adding a new child record will be able to select anyone as the owner, but after the record is saved, the owner field will automatically be updated so it matches the parent. ### Limitations There are a few limitations to be aware of when using parent/child relationships: - You cannot convert a lookup to a parent/child relationship unless all records have a value. - Once you’ve created a summary field, you cannot remove the parent/child relationship from a lookup field. - A “family tree” of parent/child relationships can only have three generations. For example: child, parent, and grandparent. - A child object can only have one parent object. - A parent object can have a maximum of 8 children objects. These limits also appear in [Custom object limits](https://developer.rippling.com/documentation/rippling-platform/custom-objects/custom-object-limits). * * * ## Related lists and related fields When editing the page layout of records, you may want to display information from related objects. You can do this by adding **related lists** and **related fields**. Before you can add a related list or related fields, there must be a lookup field linking the two objects. The direction of the lookup between your two objects determines how you can use them. - If the object whose page layout you’re editing _is looked up by_ another object, you can add the other object as a **related list**. A related list is often a set of child records, such as the line items on an invoice, or the mileage records for a company vehicle. - If the object whose page layout you’re editing _looks up_ another object, you can add fields from the other object as **related fields**. Related fields are typically from parent records, such as details from the invoice associated with a line item that you're viewing. Say you’re using custom objects for project tracking, and you have these three objects: - Object A = Assignment - Object B = Project - Object C = Client You create the following lookup fields: - A lookup field on Assignment to look up which project each assignment belongs to. - A lookup field on Project to look up which client is associated with each project. Based on these lookup relationships, you can do the following when customizing the page layout for the Project object: - Add fields from the Assignment object to the page layout of the Project object as a related list. - Add fields from the Client object to the page layout of the Project object as related fields. Related lists are displayed in a table view and give you the option to add records. Related fields are displayed in their own separate section. Examples of related lists: - Display a list of professional licenses held by each employee on their profile. - Display a list of line items on each invoice. - Display a list of the related class registrations on each class. - Display a list of follow-up tasks on each incident. Examples of related fields: - Display the name and issue date of the related invoice on each line item charge. - Display the name of the class and instructor on each class signup record. - Display the date of the incident and name of the incident’s project manager on each follow-up task. For more information, see [Record layouts](https://developer.rippling.com/documentation/rippling-platform/custom-objects/record-layouts). Source: https://developer.rippling.com/documentation/rippling-platform/custom-objects/lookups > For the complete documentation index, see [llms.txt](https://developer.rippling.com/llms.txt). Public pages have a Markdown version at the same URL with .md added.