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!

[JamesBooth]

I would LOVE to hear an update on this from anyone. This is pretty much the exact same issue I'm facing. I have over 400 "Stagnant Water Site Locations" which is my parent feature layer. Each parent record is monitored by field staff multiple times over the course of the spring/summer/fall season to collect mosquito larvae counts. Some of the fields that require filtering for certain views reside in both the feature layer attribute table on the Parent Site Location layer, and some reside in the related site visit child table.
I would like to avoid having to copy over multiple fields from the related child table to my parent Site Locations feature layer. And vice-versa if I have to filter the parent feature layer, I want the related records in the table to be filtered as well. It would be nice if ESRI took more advantage of the established relationship class and the propagation of messages/triggers.