Glide Library
In Glide, rows in our tables become items in lists & collections.
Each item has properties. For example:
  • A room can have a: number, floor, extension, desks, image
  • A team member can have a: name, number, email, image
  • A product can have a: name, SKU, image, price, description
But what if an item has another item? In other words:
  • What if a room has a floor?
  • What if a team member has a manager? Or an office?
  • What of a product has a category?
These items have their own set of properties and exist as other, independent rows. So how do we connect them? Well, that’s when we use a Relation.

Single relations

Here we can see three examples of apps where items in one area relate to items in another.
  • In the company app (left), team members have locations.
  • In the conference app (middle), events have speakers
  • In the blogging app (right), blog posts have authors.
These are examples of single relations because one item relates to another item.

Multiple Relations

But often a single item relates to multiple other items.
  • In this team member directory, each location lists all the team members that work there
  • When we go to a manager, they have a list of all the team members they manage
Creating relations is an essential skill in Glide because you’re connecting and making relationships between data. Relations are also not just used for displaying lists of information; they can be used in Choices, Charts, Computed Columns, Filters, and conditional logic.

Matching Values

Relations relate or link items across different tables. To link items together, Glide needs to have a matching value that both items share.
Let’s look at a simple team directory that has a people table and a locations table.
Two tables with the column
We want to relate team members to the locations they work in. This will allow us to do several things, including linking to their location on their profile.
In the People table, we can make sure there’s a column for the Name of the team member’s location. And of course, in the Locations table, we already have a name column with the name of that location.
Even though these columns have different names – the values in them are shared.
This is what we need to have before we create a relation.

Single Relations

To create a relation that links People to Locations we will:
  • Go to the Data Editor and add a new Relation column in the People table.
  • We’ll relate items where the value in the Location column (in the People Table) matches the value in the Name column (in the Locations table).
We can now see that for every row, a row in the locations table has been brought back. Now we can display and use that relation in various ways.

Multiple Relations

Multiple relations are configured the same way, but when many items relate to a single item, we need to check the box ‘match multiple.
For example, if we want to show all the team members that work at a particular location, we will need a multiple relation because there is likely to be more than one in every location.
We’ll go to the locations table, create a new relation column, and match items where the value in the name column matches the value in the location column in the people table.
This brings back only the first team member that works in each location, but if we click ‘match multiple,’ the relation brings back all of them.
Notice here that we had to set up two relations. 1) for bringing back the locations to the people table and 2) for bringing in the team members to the locations table.

Using Relations

But where do you use relations? What are they for?
The most common use for a relation is to display a single related item or a list of items.
In Apps, this is done with the Relation Component, Inline List, and List Relation. In Pages, this is all done with Collections.
But multiple relations can also appear in choice components and be the source for the data displayed in charts. There are also more advanced uses that we will cover in a future course.
Last modified 1mo ago