This lesson walks you through the three kinds of relationships you can create between sets of data so that you can build a fully functional, customized web app.
Home > Ontraport for no-code web apps > Custom Objects > The three relationship types
Home > Custom Objects > The three relationship types
The three relationship types
- The difference between one-to-many, one-to-one and many-to-many relationship types
- Examples of each relationship type so you can figure out how to organize your data
- The basics of intermediate objects, like tickets
- Why setting up your data properly matters
Comments
[Block//Author//First Name ##cap_first] [Block//Author//Last Name ##cap_first] on [Block//Date Added %F j, Y g:i a%+0d0h0m]
[Block//Comment]
Leave your comment
14-day free trial. No commitment.
Related resources
[Block//Resource Type]
[Block//Resource Description ##ellipsis(166)]
Transcript
Say you're a veterinarian. Your pet owners are contacts, and their pets live in a custom Pets object. That's useful, but you also need to know which pets belong to which owner. Relationships make that connection, so you can see a pet's owner from the pet's record, and an owner's pets from theirs.
There are three relationship types: one-to-many, one-to-one, and many-to-many. The type you choose decides how the connection shows up on your records, and what you can do with it later.
One-to-many is the most common. It's often called a parent-child relationship. A pet has one owner, but an owner can have many pets. So contacts are the parent, and pets are the child. Each side shows the relationship differently. The child gets a relational field, a dropdown that holds its one parent. Here, that's the Pet owner field on the pet's record. The parent gets a subcollection, a mini collection listing all of its children. Here, the owner's contact record lists their pets.
Companies and contacts work the same way. A company's record lists all the contacts who work there. Each contact just has a Company dropdown, because contacts are the child.
When you create a one-to-many relationship, you choose which object is the child. You'll do that step by step in the next lesson.
In a one-to-one relationship, a record can link to only one record in the other object. Both records get a relational field, so you can connect them from either side. For example, you could store one point of contact for each company. The company record shows its point of contact, and on the contact's record you can see which company they're the point of contact for. One-to-one relationships often play a supporting role like this.
In a many-to-many relationship, records on both sides can relate to many records on the other. An event has many registrants, and each contact can register for many events. So both records get a subcollection. The event's record lists everyone who registered, and the contact's record lists their registered events. Magazines and subscribers would work the same way.
The type you pick affects what you can do later. Reaction buttons, like favorites and upvotes, only work with many-to-many relationships. Forms can create and connect related records in one step for one-to-one and one-to-many relationships. Many-to-many works differently: it has its own form setting and its own automation element, called Update relationship. We'll cover these in the Multi-object forms and Relationship management lessons.
Sometimes you need to store details about the connection itself. Say contacts buy tickets to events. Each ticket has its own seat number, purchase date, and whether that person checked in. Those details don't fit on the contact's record, because each of their tickets has a different seat. They don't fit on the event's record either, because each attendee has a different seat.
Fields live on records, so give each connection its own record. Add a Tickets custom object in between. A contact can buy many tickets, but each ticket has one buyer. That's one-to-many. An event has many tickets, but each ticket is for one event. That's one-to-many too. Now every ticket holds its own fields. The contact's record still lists their tickets, and the event's record lists every ticket sold. Like any custom object, Tickets needs a Dynamic CMS package on your account.
Because each ticket points to its buyer, you can find the checked-in tickets for an event and send an email from Tickets to each ticket's contact, like a link to the recording.
So: one-to-many puts a field on the child and a list on the parent. One-to-one puts a field on both records. Many-to-many puts a list on both. And when you need details about the connection itself, add an object in between. Next up: creating your own custom objects, step by step.
Features
© Ontraport 2026
playlist_add_check
PCI DSS, Level 1
security
EU-U.S. Data Privacy Framework.