Hi Bubble community,
I’m trying to figure out how to approach this kind of filtering logic in Bubble. I assume it involves quite a few states and conditions, but I can’t seem to wrap my head around how to structure it all.
It feels like it would require tons of different states and complex logic or am I overthinking it?
Would really appreciate if anyone could point me in the right direction or share how you’ve handled something similar!
Thanks in advance
Hi there,
This is actually quite straightforward with Bubble’s standard constraints - depending on how you’re handling filtering, you can do one of the following or a combination:
Use the ‘go to’ workflow action and send page parameters as the users select them, and then use ‘get data from URL’ for each constraint
Or
As filters are filled out, update a custom state, and refer to the custom state in your constraint
Or
Use the actual input elements as the constraint data source (i.e. “Name Contains InputName’s value”)
I do a decent combo of all of these in my cocktail app, www.knowthydrink.com - look at the filtering parameters and how the URL is updated as you hit ‘Search’
Happy to answer any questions you might have!
Hey @msgiblin, thanks a lot for your comment and great job on the filtering setup on your site!
I’ve managed to get the basic filtering to work using page parameters like city=London&gender=female, which is super helpful. However, I’m a bit unsure how to handle the “not equal to” case in URL parameters, for example, how would you go about excluding a city like city≠London in the page parameter? so the reapaing group shows all users from all citys except London?
Would you mind explaining how would handled that part?
Thanks again! 
Maybe the url key parameter should be “excluded-city” 
Hey @Sarah_Esteve, yes but it’s more the workflows im concirned about, lets say one user needs to filter:
Team contains Marketing | Role = Markering | City is not London | Status = active
And then another time wants to filter:
Team does not contain Marketing | Role is not Markering | City is New York | Status = active
I feel like i need 1000 different workflows with conditions to set this up but i might be doing it the wrong way or?
@msgiblin @Sarah_Esteve im trying to tackle it with chatgpt as well, it says I should use it like the following for the repeating group, is towards the correct way?
Search for People
Team contains Get URL(team_contains) (ignore empty)
Role = Get URL(role) (ignore empty)
City = Get URL(city) (ignore empty)
Status = Get URL(status) (ignore empty)
:filtered (Advanced)
(
Get URL(team_not) is empty
OR This Person's Team doesn't contain Get URL(team_not)
)
AND (
Get URL(role_neq) is empty
OR This Person's Role ≠ Get URL(role_neq)
)
AND (
Get URL(city_not) is empty
OR This Person's City ≠ Get URL(city_not)
)
AND (
Get URL(status_neq) is empty
OR This Person's Status ≠ Get URL(status_neq)
)
I might need to do some testing on this, but I feel like you can get this without using Filtered:Advanced, which can be very heavy in terms of WU usage and skower on performance as it typically loads all results to the browser session and filters them client-side.
What I would look at instead are various hidden repeating groups (or custom states) that perform searches for the omitted items. Then in the main results, use the Minus List operator and reference that hidden repeating group’s results. I’ve seen some users refer to these hidden repeating groups that hold data as ‘variables’ and the naming convention might be something lile “VAR Omitted Cities” where the VAR prefix indicates its hidden nature as a variable. They can be more flexible than custom states as the data is dynamic and live with any other updates in the database.
Interesting with hidden repeating groups! i need to look in to this to store the information for sure. But I’m still confused about the workflow for when an option is contains for example and another on is “not empty” how that would look if i need 100 different workflows with different conditions like “When city is contains” etc?
The concern with hidden repeating groups is that they will load all fields for every item of the data type. This is generally fine as long as there aren’t too many fields on the data type, the fields themselves are lightweight (for example, lists of items are not lightweight), and there aren’t too many items to exclude. If you end up with thousands or tens of thousands of items, forget it. Also, note that a state cannot hold too many items (the maximum is about 2,000).
What you can also do is send parameters to a backend workflow, triggered by an API call, and return a list of IDs to exclude (advanced bubbling 
).
This won’t help you achieve exactly what you are after, but it will solve the problem in a simple and maintainable way. Make sure all of the filtering fields exist on your primary data type, even if you need to duplicate the data from peripheral data types onto the primary data type.
Then avoid “advanced” filters altogether and write your search like:
Do a search for [data type]
Where
Field 1 contains [input 1]
Field 2 contains [input 2]
Field 3… etc.
Ignore empty constraints = true.
It may not be as nice as what you’re trying to do, but it’s a good basic starting place and if it meets the business case it will reduce the time cost significantly.
Otherwise, go with what the others have said. Just try not to have 16 different versions of your search in conditionals on the repeating group or you may go crazy…