Complex question about matching

I have a lead generation platform that connects consumers with moving companies. Moving companies can set their service areas at the city level. I want to match them with consumer requests based on both the current city and the moving city. Currently, my platform in Bubble only considers the city of the current address for matching, but I want it to also consider the moving city. This means that the set service area should include one of the two City, not just the current one.

I have both the fields in my database as ‘City’ and 'Moving City

It would be great to add a operator to “Werkgebied” (Service area in English) and use a “or” operator, but that is not available

Provincie = City

Use advanced filters. After your search for open campaigns add :filtered and then type in advanced. Then you can get some other operators and play around until you get what you want.

1 Like

Will test and update you! One question, will the other constraints still be working when i use this advanced filtering?

Yep. And you’d better put as many constraints as possible within Do a search expression cause Advanced... filtering is performed client-side (so it influences performance and WU consumption cause Bubble will fetch more items from the DB for advanced filtering)

1 Like

Since this is a lead gen platform I’m going to assume you’re going to have a pretty hefty number of db rows you must filter through. You will not want to use advanced filtering on large data pulls. It’ll be slow and heavy.

When using advanced filter you’re going to basically have bubble reiterating that initial search a minimum of 3 times.

Once on the do search for… once on filter and once and advanced.

If you have 10,000 items you do that on it’ll be a sluggish nightmare.

Rather, try looking for an alternative solution, few potentials off the top of my head.
1: change UI to fit your flow better (ex separate search field for moving from / moving to)

2: Keep current UI add a new data type called “address list” which is a “list of addresses” on lead. All this is is the moving from & moving to addresses in the same field.

This way you can do something like “do search for” contrained address list contains “searched city”. (This method is commonly used for things like key wording)

That’ll reduce recurring workload that you’d have to have with filter/adv filter and won’t see performance degradation with db size.

May want to use DB triggers for anytime a to or from address field on lead is updated it updates the “address list” field.

Filtering and adv filtering should be your last choice & typically used only on smaller datasets if you must use it. Many times adding a field or restructuring data can completely avoid it and maintain search and app speed.


Hi Chris,

Thanks a lot for your reaction. That also was a idea of mine but i didnt thank that would work, to have a list of “City’s” in the Leads data field.

Can i add a constraint There to say something like “is in” or something?


Yes you may also be able to do it with something such as :formatted as list:plus item to get both addresses in the search

Or RG list of leads actually include 2 searches

Do search for leads (constrain from city = user searched city):merged with do search for leads (constrain to city = user searched city)

I don’t know your app but their are ways to avoid filter/adv filter just gotta get crafty.

1 Like

Hi Chris,
I am testing this now, but no results so far.

Created a RG and here comes al of the “potentials” who can get the lead. And added a new field called “Provinices” = (City’s in English). This is a text type, and a list. I added both the current city of the lead, and the moving city to the list.

But, no users show up. So I think this is saying “Only when werkgebied contains BOTH Provincies” , but I want it that is needs to be show up when one “City” on the users field matches the Service area of the user (Werkgebied).

Schermafbeelding 2023-09-08 om 07.39.26

This topic was automatically closed after 70 days. New replies are no longer allowed.