Table relations & choice as filter

Hi there, I am struggling to use a choice as a filter with following structure.

I have

The properties relate like this:

The target UX is like this

Step 1
User chooses one TOPIC only

Step 2
User is shown a list of CONTENTS & can filter the CONTENTS with the “choice” component according to the SUBTOPIC (the “chips” are SUBTOPICS).

Can anyone help? I am getting frustrated.

Thanks a lot!

For second choice component, you’ll need to add a filter that filters by “screen > (1st choice component value”

1 Like

Hi Robert, you have been a master for me so far! Thanks for all your tutorials and support.

I watched the “INIFITE and DYNAMIC Filtering!” however my case is slighlty more complicated due to:

  • The “write to” destination is the TOPIC table, but the rows I want to filter are in the CONTENT table and the choice source is in the TOPICS & SUB-TOPICS table.
  • Also the choice is multiple selection

The project has only 1 Page “Scegli un tema” with a collection of “Topics”

I am working with the following tables:

  • TOPICS (with: relation with “Content”, and relation with “Topics & Sub-Topics”)

The user chooses a Topic

The user is shown with Sub-Topic choice which can be used to filter the Content collection below.

I think I have to bring values (for example “tools” and “nft”) written by the choice component, from the TOPICS table to the CONTENT table as a first step, and then implement the single value column and if → then in order to make the filter work.

Hope it wasn’t too long such description.

Thanks a lot for your help!

Multiple choice filtering is a bit more complicated, but still very achievable. Also, when adding custom filtering, I recommend making the source of your page the users table. That way you can write the filter values to a user specific column In the user profile table so it can be accessed anywhere.

I should really redo my filtering video to explain this better. That will be on my docket today.

Great Robert, thanks a lot. My Glide Page has optional login. Will the solution you said work anyway also with optional login?


Now that you brought this up, from a design perspective I read (thought I read/thought I understood) that you should not use the ‘user profile’ table except for ‘user’ info from a security perspective.

But the user profile is the one table that is accessible in actions, visibility and filters so it has become a very wide row with lots of USC/xxx columns with many templates/filters plus relations and is the source for four of my five TABs and many ‘New Screens’,

Is this a reasonable/usual best practice? I especially needed access to data within actions which have a very limited scope.


I’ve done it multiple different ways. Using the user profile table as the source is one solution. I’ve also used separate single row tables to serve as the tab source and to hold user specific values. It’s all personal preference. As @Robert_Petitto pointed out, using the user profile table makes it much easier to access those values throughout your app. If you use a separate single row work table, then you just need to use Single Value columns to pull those values into other tables, so they can be accessible for actions, filters, etc.

I don’t think there’s really any advantage or disadvantage either way. It’s just how you want to structure your data, and the methods to access that data just differs slightly.

Also want to point out that if you use the user profile table, you don’t need to use USC columns because each row is specific to a user. On the other hand, a single row work table should have USC columns because all users are sharing the same row.


I never really understood the Single Value column and its usefulness nor a single row work table when you have multiple users. I have seen @Darren_Murphy reference and use them but I have not understood them and how they could be used in a multi-user environment. I can’t get my head around it :slightly_frowning_face:

Is their an example video (@Robert_Petitto ) on how/why this technique (single value columns plus single row work table w/ USC) should be used and the benefits?

PS - thanks for the USC column hint…thinking about it I guess I don’t need them

USC columns allow multiple users to enter a value into the same cell without other users seeing what someone else entered. It allows for a completely unique experience for each user. That’s why a single row table with USC columns works. Each user is editing the same row, but the values they enter are unique to them.

When used in conjunction with Single Value columns, you can set the single value column to pull from the first row in the table, because that will be the only row in the table and that’s were all the values will be. Since the table has USC columns, the value that the single value column pulls back will always be the value that is specific to that user, and from that first and only row.

If you instead use Roberts method, your tabs will use the user profile table, but you first need to make sure that the user profile table either has Row Owners enabled, so only the signed in user’s row is downloaded and the tab will automatically be linked to that one user row…or you need to make sure your tab is filtered by signed in user, so you can guarantee that you values update on the correct user row. If the values on correct the user row are being updated, then you can access those user profile values throughout the app without having to create single value columns to pull the value into other tables.

Another tip with the Single Value column…if you have a multiple relation, you can use a single value column to pull back the value from the first, last, or a specific row within that relation, as opposed to looking at the entire table.


Hi, I am new to Glide so this to me sounds difficult. I wanted to clarify that for now my Glide Page is Public, no need to store user information. I just want the list to be filtered through the choice component.

I would have use the built in “show filter” option of the list, but: it’s only single choice (not multiple), plus it’s only a drop down (no “chips” UI).

How do you do that?

Thanks for patience.


Single value columns enable me to ‘add’ columns within tables that I can then filter/ITE within actions without resorting to stuffing my user profile table.

A lot of my ‘user profile’ usage is trying to get access to data from actions or filters. Instead I can user SV and USC-based working tables to achieve the same result. Can SV be used with filters within an inline list? Are their restrictions to SV access or are they treated kinda like a basic column?

@Filo You can keep your app Public and still use user specific columns for your filters. They work whether a user is signed in or not. The only difference is that if a user is not signed in, then those values will reset to empty when a user closes the app. They aren’t saved.

In your case, having a single row table as you driver for your tab should work. Make sure you have one row and that you use user specific columns to receive the choices and values that the user enters. Then you can filter your list using those values.

Yes, a single value column is treated just as if it’s the original column value. You can use them for filtering an inline list as long as that single value column is added to the table that is the source of that inline list. You may also be able to skip the single value column by setting your filter to use the Screen Values, which is any value on that current screen, such as the USC columns that are set by you choice/text entry filter components.