Multi Filters using Relations: a new way 💡

Hola, feliz día!

Watching some threads and good Robert Petitto’s videos about creating customized filters using an Inline List component, I thought an idea to make it simpler and avoid configuring manually the Inline List’s filter and suddenly, I got this to share :wink::

  1. A way to have a wide Filter using the OR operator

  2. A narrow Filter using the AND operator

I recorded a video to show and help to understand how this APP demo works and its procedure: Loom | Free Screen & Video Recording Software

The trick is to work with a multiple relation base on values (filters) selected by user which will rule your Inline List data and as you can see, you don’t need to configure/create internal filters later.


You can copy my demo APP and learn better the procedure if you want:

I hope it helps and complements Robert’s effort on this topic.

Saludos a todos!


I like what you’ve done with the template/split text combination.
Although I’ve been creating these types of dynamic relations for quite some time, it’s always been a combination of template + if-then-else. The split text approach never occurred to me, but having seen what you did here I think it’s a better (cleaner) approach. Nice work :+1:


Nicely done!

1 Like

Thank you for the demo… w

1 Like

Excellent, thanks for sharing!

1 Like

Hola Darren,

Glad to see my solution gives new ideas to other situations.

Another advantage with it is that you can have quickly the amount of records the filters bring back due to it is working with a relation. Any Rollup pointing to this relation will give you the amount.

I think @kyleheney was looking for something like it weeks ago.

Happy weekend friends!


This is amazing.
Wondering whether it’s more lightweight than this method by @Robert_Petitto especially when it comes to multiple filters.

1 Like

Hola Eden!

My original idea was to create a kind of “SQL Query” inside Glide although the big troubles came from playing/working with parameters using an OR operator and AND operator at the same time (a hard challenge sometimes in GDE).

In the end, a Filter is almost a SQL Query when you try to narrow your useful data.

When I ended this idea, I evaluated if this had been a good solution ( a clever idea) or on the contrary, it might create more load/work for Glide (unnecessarily) due to use of template columns changing dynamically along with relations based on them.

To sum up: the endless dilemma between Efficiency vs. Effectiveness when our APP is using this method with a large amount of data: 15k or 20k+ rows :confused:

I don’t know at the end whether the best option is to load all data once and let Glide filter and discard values/rows automatically or create/use a dynamic relation to get a specific result always (my idea). Which process is better for Glide? … I don’t know yet

I read @Darren_Murphy and @Jeff_Hager discuss about this issue here and I agree with some points but I think the friends @Mark or @Jason can give us the final answer to have the best performance on our APPs always.

Have a nice weekend… feliz fin de semana!


In my experience, filtering any list (whether by condition>relation>inline list OR inline list>condition>filter) is considerably laggy when that condition is built off of an earlier rollup of a datetime.

For example:

Log of categories and dates > relation to self of log categories > rollup of earliest date > if rollup is date then true >filter inline list where if = true.


Question is, in this instance you only have one row with compute columns and then the relation is built on top of them -

Perhaps as it is a single row it uses significantly less resources than if it were lots of rows -
In which case the conventional way of looking at it doesn’t apply.

Also wondering whether lots of users using a user specific column then having compute columns like template on top of them (and then a relation) -
How many users Glide can handle

All computations are done on the users device, so Glide can handle it pretty readily when it’s a user specific instance


That’s right!

To me, it’s the best way to do this kind of operations and avoid affecting other columns/tables by accident. I just try to use/put a relation where there is no much data (or few columns) involved or associated to that relation and “help” Glide a bit during the table updating.


1 Like

The assumption is very sound,
The question is whether it’s true, especially with multiple compute columns.

But since it’s only a single row with user specific compute - and it doesn’t compute the bulk of the data - only this row and pulling the relation columns accordingly - perhaps it can handle much much more -

I was thinking maybe start using this method always.
Instead of having users entering actual screens, just go virtual, like this method.

For instance I Have projects, in this project I have multiple related Tables; “Openings”, “Types”, “Records”

Instead of Going into a detail screen of the project and pulling up the related Inline lists, I would just have a virtual screen which pulls up the inline lists -

Therefore I won’t have to build Template/compute columns and relations directly within these Tables which are rather large

@Robert_Petitto what do you think?

1 Like

This works. I do this method at times for one-screen dashboards. Often, as you say, for switching between projects or dates.

CleanShot 2022-01-22 at 18.50.03