Good day everyone. I have a layout with a table that has 2 other duplicates in the layout. Each one is filtered according to a choice field in the table - has both elements, only the 1st, only the 2nd. Works fine. Since the tables have titles, I want to make visible only the tables that are not empty. (Choice 1 has no entries.) But the visibility settings only allows choices from the profile and the default tab.
Is there a way I can prevent the title from the empty table being shown?
So you have 3 table components in the layout, each one will be shown depending on a value from a choice component? Or will they all be visible and you just want to hide the titles?
I think hiding tables make more sense, but awaiting clarification.
Hi @ThinhDinh . Yes hiding tables makes more sense and this is what I want to do.
As shown in the first screenshot, table 2 is empty because no record fulfills the filter criteria (duh.. 
). But the title and column headings still show.
I cannot hide the table because there is no applicable option in the visibility setting. It only allows fields from the default screen (Welkom) and the user profile.
So if hiding the table makes more sense, how do I do it? Even if these tables are in containers there still is no way to set visibility to a field in the table,
The filtering is based on a Choice component, yes?
If so, target the choice component at a column in the User Profile row, then you can use that as the basis for visibility settings.
Good day @Darren_Murphy . I do apologize, the word âchoiceâ is misleading. I actually referred to the choice the user makes when booking a trip for their child - going home, only, back to school only or both. The 3 tables are then filtered according to each choice since the choice is recorded in the Trips table.
This is the filter for the empty table:
It is not a major issue, would just like to clean up the interface. And wondering why the Visibility filter cannot be based on the table in use.
You might be better off creating a query column for each table, and do your filtering within the query column. That way, you can set the source of each table to be each respective query. You wonât need to set any filters on the tables sources from queries because the query is handling it.
This will give you the option of setting a visibility condition on each table to only display if the respective query is not empty.
You might be better off creating a query column for each table, and do your filtering within the query column.
This is the result:
All correct.
Since nobody is booked for the trip home only, the -H column is blank.
Different names in the -S column, kids booked only for trip to school.
you can can set the source of each table to be each respective query
Took me a while to find out those sources are at the bottom of the list 
âŚ.
This will give you the option of setting a visibility condition on each table to only display if the respective query is not empty.
Fantastic! Thank you.
However, is the only way to use a query as a table source to put it a custom container? I tried a normal container but then the queries are not available. Now the tables all repeat within the custom container. I know I have to filter the container on a unique column but I havenât found one yet.
Containers should have no bearing on how this works. Whatâs important is which table and row the screen is attached to. If the screen is attached to a row that contains those queries, then it should be really easy to add your tables sources from those queries.
The only difference with a custom collection container is that each item in that custom collection is linked to its respective table row.
My guess is that you put those queries in the wrong table. Put them in whichever table is the source of your screen.
You canât directly hide a collection title just because the collection is empty â visibility rules only look at profile/default values, not the live filtered result. The workaround is to create a data flag (for example a relation + rollup count that matches the same filter). Then set the title to show only if that count is > 0. That way any table with no entries simply wonât show its title.
Good day @Jeff_Hager . Let me see if were are on the same page.
Containers should have no bearing on how this works
If I put the table outside of a Custom container, I do not have the query to connect to in the data source.
But inside a custom container:
Whatâs important is which table and row the screen is attached to. If the screen is attached to a row that contains those queries, then it should be really easy to add your tables sources from those queries.
My guess is that you put those queries in the wrong table. Put them in whichever table is the source of your screen.
This screen is a list of booking details for all the children booked for the upcoming weekend. It is therefore attached to the Ritte (trips) table and the query is in the same table.
@Theo_Phyl , Thanks, your suggestion makes sense to me. I will try it out soon.
Are you sure? Of course, thatâs the screenâs purpose, but all I see for components are collections, which could be sourced from any table, and static text that doesnât appear to come from any table column. In fact, I donât see any components on your screen that necessarily depend on data from the table and row that the screen is attached to.
I canât tell from your screenshots what the table source is for the screen itself. It could be any of your tables except the table that contains those queries. When you view the configuration options for the tab or screen (not the configuration of any component on the screen), are you still connected to that same table? I doubt that screen is. Otherwise you would see the queries.
Good day, thanks for the info. Itâs very helpful to know a bit how Glide works. I have a question about this visibility setting. You said
visibility rules only look at profile/default values
I have a grid with trip data for Friday and one for Sunday where Admins can edit data inline. The visibility filter allows me to select a table column vale and compare it with a profile value. Same as what the grid filter does. So the column value is a DT like
10/17/2025, 11:34:56 AM
and the profile value is
10/17/2025, 5:06:21 PM
This formula works perfectly in the grid filter but hides all the records in the visibility filter:
I want to know why??? The option is available in the visibility filter so should work, right? Just to muddy the waters further, DatumS is on or after Today and DatumS within Today does not work
but DatumS is before Today and DatumS is not Today does
and within works in an ITE formula too.
So obviously Glide is factoring in the Time component too, for a Date field. I know DT is actually the number of milliseconds since Bill Gateâs birth or something but how on earth do you use a pure date or pure time value in a comparison? Gide docs say
Parts enables you to decide if you want to store both the date and the time, the date only, or the time only.
Note that it says store the part. But if you set a Date column value (that is a Short Date) from a workflow calculated date (which you CANNOT configure a a date part), the Date column value is a DT value again. Never mind its actual configuration in the table.
Three last remarks out of left field.. not part of this issue but something I noticed often. When editing any calculated field in a table, if you escape immediatley withou even putting your cursor in the formula screen, Glide still wants you to Discard changes. It is not the case for text and number fields. So Glide does nou actually track if there has been a change in the formula.
Also, are the list of updates published anywhere? Whenever my work gets interrupted by an update message, first thing I want to do is check what is new. This info is not available in the Community Announcements.
Lastly, should I put in a feature request for glide to make the horizontal scroll bar higher? I have 231 colums in one table and every time I scroll to the right, I add a new record,
Your filter checks the date in each individual row within the collection to determine which row to display. Visibility only looks at the row that the screen is attached to. If itâs the first row I. the table and the date does not fit the criteria, then the entire component is hidden. Filters filter a collection of multiple rows of data. Visibility just determines if a component is visible or not based on a single row.
âOn or Beforeâ and âOn or Afterâ both consider time in a date column. âIs Withinâ only considers the date and ignores time. Again, I must stress that you need to consider the table and row that your Screen is attached to, especially when using visibility conditions,because they will be based on the values in that singular row.
What you are talking about is Unix time, but that does factor into anything here. You are already comparing pure date and time. Nothing do to with time elapsed since Jan 1 1970.
Date columns ALWAYS store date and time regardless of what you set for the forward facing format. Always consider that underlying time. What is different is that if you use a date picker, it will only store a time of midnight whereas a date and time picker will store whatever time you picked.
Any other updates that occur are most likely big fixes not worthy of release notes.
Wouldnât hurt.
