Filtering Related Records without filtered field in child table

[Fendley]

Hello! I would like help filtering related records that do not contain the fields that is being filtered on.

My Data:

I have a point layer called "Projects" with a numerical field called "Weight".

Each Project has several "Quotes", which are stored in a related table. They are related by the "ProjectID" field.

The Quotes layer does not contain the Weight field.

Experience Builder:

I have set up a filter that allows users to select a Weight range on the Projects field. This filters the Projects on the map.

I want the related Quotes to be filtered as well, even though Quotes does not contain the Weight field. Is it possible to filter records based on the common field, ProjectID?

I simplified my scenario. I have several layers of nested related data with many fields. Unfortunately, it is not realistic for me to add all the fields I need to each level. I'd imagine there has to be a way to do this, but I can't figure it out.

Thank you very much!

[ShengdiZhang · Accepted solution]

Hi @Fendley ,

Unfortunately, we now have limitations on simultaneously filtering data from the Parent and Related tables.

The message action Record selection changes - Framework - Filter data records, supports filtering related records, can this be a workaround for your app?

Regards,

Shengdi

[Fendley]

Thank you for reply and confirming the limitation. This workaround doesn't quite work for my organization due the complex structure of our data. I hope filtering related data filtering is added in the future!

[JasonBOCQUET]

Hi @ShengdiZhang the case that describe @Fendley it similar to what I need to do in my organization.

Actually with the message action Record "SELECTION" change, you can simulate a filtering between parent and related tables. But, it's very annoying for the users to be forced to select multiple lines on a table or multiple points on a map to have the related table actualized.

This is not possible to make an another message action record based on filtered change rather than selection change ?

And you speak about "limitations", there is a plan to raise these limitations ? Have a dynamical parent/related relation who's dynamically actualized seems to be a "basic" feature who need to be present in EVERY tools/application. When we work as an enterprise we are forced to structure our data correctly with some rules to have a database very clean. Be forced to add useless columns just to dodge a design problem is very annoying. In my case i have to add 10 column only to filter the transaction on my buildings when my users filter the building layer.

I don't want to be unpleasant but I don't understand how in 2025 we can be blocked by a conceptual thing that is so necessary to have in order to be able to implement fluid and efficient applications.

[Fendley]

"When we work as an enterprise we are forced to structure our data correctly with some rules to have a database very clean. Be forced to add useless columns just to dodge a design problem is very annoying. In my case i have to add 10 column only to filter the transaction on my buildings when my users filter the building layer."
Sounds very similar to my challenge. 

My current workarounds are
1) Using query layers (slow!)
2) Adding fields (too much data!)

Kindly let me know if you find a better workaround. Cheers!