I’m building a screen with a 3-level category structure using separate data tables for each level: Level 1 (Service Categories), Level 2 (Service Providers), and Level 3 (Provider Services). My goal is to create a seamless navigation flow where:
Level 1: Users see a list of “Service Categories” as a collection.
Level 2: When clicking on a category, users are taken to a screen showing only the related “Service Providers” within that category.
Level 3: Clicking on a specific provider reveals a final screen with the “Provider Services” for that provider.
What I’ve Tried
In the Service Providers table, I added a relation column (serviceRelation) that maps categoryId between the “Service Providers” and “Service Categories” tables. The relation appears to be set up correctly.
I created a custom screen sourced from the Service Categories table, displaying a collection list. This works well, as I can see and select different service categories.
In the Level 2 screen, I added a collection card sourced from the “Service Providers” table. However, I encounter an issue here:
Filtering: I applied a filter using “serviceRelation is not empty” in the options, expecting to see only the relevant Service Providers for each selected category. Unfortunately, all Service Providers across categories are still visible.
Static Filter Behavior: If I set a specific filter like “serviceCategory is anycategory,” it correctly filters the Service Providers. However, changing the selected category at Level 1 doesn’t update Level 2 dynamically. All second-level screens show the same filtered category, regardless of the initial category selection.
Question
Is there a way to dynamically filter Level 2 and Level 3 screens based on the selected Level 1 category, so that each screen only shows the relevant subcategories? Any advice or workarounds would be greatly appreciated!
For starters, you should be sourcing your second and third level collections based on the respective relations. You shouldn’t need a filter.
It gets more complex if level 3 is dependent on both the selected items in level 1 and 2, but I’m not sure if that matters in your case.
You can still filter by screen values (not the relation, but values from the parent row), but I prefer to rely on sourcing the collection from the relation since it provides added benefits if you need to use things like lookups, rollups, etc. in the future.
Thanks for the insight @Jeff_Hager ! I believe I am following your advice by sourcing the second-level collection directly from the serviceProviders table, which has a serviceRelation relation column to serviceCategories.
However, even after removing the filter, I’m still seeing all service providers across all categories, regardless of the category selected in the first level.
As shown in the image, I’m sourcing directly from serviceProviders with serviceRelation as the relation column. It seems like the relation isn’t dynamically filtering the items as expected based on the selected category in Level 1. Am I possibly missing a step, or misunderstanding something in the setup?
No, I said to source it from the relation. Your Service Category table should have a relation to Service Providers. When viewing the detail screen for the selected category you then source the provider collection from the relation. Not the table.
I have found the problem. I was creating the relation column in the 2-level table and it had to be created in the 1-level table so I can see the relation as an option to source it in the 2-level screen.
