Select to view content in your preferred language

2025 plan to improve filters on experience builder ?

85
0
Friday
JasonBOCQUET
Frequent Contributor

Hello, I want to ask and discuss the topic of filters.

In the past, with Experience Builder, filters were very limited. You could only filter on one layer. For example if you wanted to filter buildings by surface area on one side and view related transactions about these buildings in a table (from another data source) it wasn't possible to dynamically update the transactions based on the building filter.

Since 2024 with the introduction of Group Filter, it's now possible to achieve this. However, you still need to have a shared field between the 2 data sources. While this isn't too hard to manage by using SQL, it's conceptually frustrating to create unnecessary columns in your data model just to enable dynamic filtering across different data types.

I give you an example : in my case I have buildings, offers (e.g., if 1000 m² of a building is avaiable for sale) and transaction history (e.g., the 1000m² were sold for 5$). My users want to filter atthe building level, as this is their primary focus for analysis. They mayfilter by square meters, building type, etc and if an offer is actually avaiable on the building. So by a group filter I can filter by my "TAG_OFFER" field (it's just a yes/no information) present on the building table.

However, if i wants users to see transaction data for buildings with active offers, i'm forced to create the same "TAG_OFFER" field in the transaction table. And this is problematic because, in the conceptual model of our database, the transaction table has no legitimate use for this field. It exists only to make the transaction data dynamically filterable based on user selections for buildings.

 

Here's my question and the point I want to talk with you :

Are there any plan to update filtering functionality in 2025 to allow for more dynamic filters between data sources without requiring the addition of unnecessary fields in unrelated tables ?

The most efficient solution, in my opinion, would be this : If my building has an ID 'ID001', all related transactions and offers already have this building ID as a foreign key. When i filter on the building layer,  all other data source of data (preselected during widget configuration) should automatically filter based on this building ID.

 

And i know there are actions that can be set in the Map widget, but they require users to manually make a selection on the map, which is inefficient. 

 

What do you think about this ? I hope there wil lbe improvments to filtering functionality this year. 

0 Replies