Let’s say I have a table named Reports, which has a connection to Locations. In the Locations table, each Location record has fields like Name, City, State, etc.
I created a Page with a Table View that displays the Reports table. However, I want to filter the table so users can only see reports that are connected to Locations where State=NY. So the filtering is done not on the main unique “Display Field” (Name) of the Location record, but on one of its other fields.
I don’t see an option to do this with the available filtering mechanism. It only allows me to filter based on the main Display Field (i.e. Location Name = some name). But I want all Location Names/records where the Location State field = X.
I suggest on your Reports table also having a connection to the States table (assuming you have one).
Whenever a report is created, you ask for both a State and Location (or record rule when selecting just the Location that populates the State).
This way you can add a grid/table view that shows Reports connected to the logged-in Account’s State(s)
Thanks for the response. Yes I guess this is a possible solution, so actually instead of using “nested” filtering (i.e. filtering by the other fields of a connected record (not the default “display field”), we can “flatten” this by making a special table and connection to each field that we want to filter by. However, I still think this is a very helpful feature (request?), because it allows great filtering capabilities without creating more and more tables and connections just for this type of filtering. I mean, the connection is already there, so why not use it to filter by other fields of the connected record?
(In our example, let’s say I wanted to filte rby State, and by City, and by Zipcode.. I’d have to create 3 more tables and make all of these connections, even though we already have a connected record based on Location which “contains” all of this information).
You won’t necessarily have to create separate tables for City and Zipcode. You’d only need it for State because that has a connection to the logged-in Account.
The Locations table, where City and Zip are text/number fields, and State is a connection field:
Nice! Yeah I didn’t mention the logged in user thing because I didn’t want to rely on having this require a login (allowing it to be a public page). But indeed this would work. Thanks!
