This plugin is an advanced version of our Fuzzy Search & Autocomplete plugin. The plugin allows searching for not-perfect matches accounting for typos and close matches.
Features:
-ability to search the Bubble database using the “Search Pro” element and the Airtable database using the “Airtable Search Pro” element.
-sort search results by one of the database fields.
-using advanced search.
-ability to search by geo-location
Found a possible bug. With the dropdown suggestions, the suggestion box location does not follow the input it is trying to stay under. For example, when elements displace the input due to collapse on hidden settings. See screenshots below.
Screenshot 1 – everything ok, as this is how it initially loaded on screen
Screenshot 2 – a hidden group displaces the input text. The suggestions box shows up back where the input was at originally, not at when performing a search
We are sorry to hear that you encountered an issue while using the plugin. We have reproduced the issue on our side and have already sent this information to the development team, they will fix it soon and we will get back to you.
We are excited to share that we have effectively resolved the issue with the Fuzzy Search Pro action and have updated it to version 1.21.0 (fixed position suggestions on the page).
Could you kindly update the plugin within your app to this latest version and confirm whether everything is now operating smoothly?
Feel free to explore the plugin’s functionality on our demo page.
Your patience and cooperation throughout this process have been greatly appreciated.
We’re happy to announce a new improvement for the Fuzzy Search Pro plugin, now with more advanced possibilities for Plain Text Search!
With this update (Version 1.24.0, released 12.09.25), you can now set the data type as “text” and the data source as “list of text”.
This enhancement makes it possible to search directly over a list of texts, offering more flexibility and simplifying text-based searches in your Bubble app.
I’m currently using this plugin to search data in a table, but I’m running into a weird behavior with the plugin.
My data source is pretty simple: I search for Users where status = a custom state (this custom state can be any status).
The issue is that the plugin only seems to react to the first value of the custom state. When I change the custom state (by selecting another status), it updates correctly, but when I run the search it still returns results based on the initial status I chose.
Has anyone experienced this before or knows what might cause it?
I also tried changing the data source conditionally.
For example: if custom state = status1, then I set the data source to status = status1 (so the final data source doesn’t rely on a custom state anymore).
The issue could be related to how the plugin is responding to changes in the custom state. One possibility is that the plugin isn’t immediately picking up the new custom state after it’s updated.
This can sometimes happen due to how Bubble processes state changes and triggers.
Here’s what you can try:
Make sure the custom state is updated correctly before the search action is triggered.
Use “Only When” conditions to confirm the custom state has been updated before the search runs. This can help ensure the plugin is reacting to the correct value.
If the issue continues, check if there are any workflows or triggers that might be conflicting with or overriding the custom state.
If the issue still persists, feel free to share more details or workflow screenshots, and I’ll be happy to dive deeper and help you out!
Plugin action Server Side Search error:
TypeError: current_object[i].get is not a function
at makearray (eval at build_function (/var/task/util/util_harness.js:37:12), :64:51)
at eval (eval at build_function (/var/task/util/util_harness.js:37:12), :81:15)
at async /var/task/plugin_api_v4_alpha.js:197:29
at async harness (/var/task/harness.js:115:15)
at async /var/task/harness.js:152:64
at async withGlobalHandlers (/var/task/harness.js:66:10)
at async Runtime.myHandler [as handler] (/var/task/harness.js:152:10)
Thanks for reaching out and for sharing the screenshots and error details — appreciate the clear context.
The error you’re seeing with the Server Side Search action is expected in this specific setup and is related to how Bubble handles lists of texts in server-side actions. When a data source is set to something like Search for Companies:each item's Company Name, Bubble passes this to the server as a raw array of strings. On the server side, these strings don’t have getters, which causes the error you’re encountering (current_object[i].get is not a function).
To avoid this, we recommend passing a list of Things instead of a list of texts. In practice, this means:
Set the Data Type to your Thing (for example, Company)
Set the Data Source to Search for Companies
Specify the searchable field (like Company Name) in the relevant input of the action
This way, the plugin works with full objects, which are fully supported by Bubble’s server-side runtime. If your use case strictly requires working with text values only, the client-side action supports that scenario correctly - the limitation applies specifically to server-side execution.
Could you let us know whether this workflow must run server-side, and what the main goal is (for example, performance, privacy rules, or handling large datasets)?
With a bit more context, we’ll be happy to suggest the cleanest and most reliable setup for your case.
Yes the issue was a large dataset i.e. setting a Data Source as not text but a Data Type errors back (I think it has a 6 or 8 mb limit). But that’s not a big issue, I can process it in chunks no problem.
However, another thing:
Match Scores looking weird to me. Docs say “Match scores from 0 to 1. 0 is a perfect match“
When testing this on a test dataset, found that what looks like a perfect match (so the score should be 0 I think?) returns, in fact, the biggest score = far more than 1
Here I search for the company name “email test“:
There is also another problem that when running identical search in the backend wf’s seems that the “server search“ action doesn’t return any matches or scores, even though it does them in the set up above. I can provide details but let’s perhaps sort out the scoring thing,
Thanks for the detailed follow-up and for sharing your test results and screenshots — that context is extremely helpful.
On the match scores, what you’re seeing is expected once we look at how the scoring works internally. While the docs mention scores “from 0 to 1,” the key rule to rely on is that lower scores indicate better matches. Values very close to zero (including scientific notation like 1.49e-8) represent an almost perfect or exact match. These scores aren’t percentages; they’re relative distance values used for ranking results. Because of that, broader searches with many partial matches can produce higher numbers, sometimes greater than 1, while exact or near-exact matches will approach zero.
In your examples, searching for a unique term or the full company name and getting a score near zero is actually the best possible result, even if it initially looks counterintuitive. For wider queries such as “email test,” the spread of higher scores is expected. We generally recommend treating the scores as relative rankings (lowest score = best match) rather than enforcing a strict numeric range.
Regarding the backend workflow returning empty matches and scores, that’s likely a separate issue. Backend workflows are more sensitive to context, inputs, and privacy rules, so identical logic can behave differently compared to page workflows. Once the scoring behavior is clear, we can investigate that part in more detail.
Could you let us know how you plan to consume the scores on your side (for example, lowest score only, threshold-based filtering, or sorting)? Also, can you confirm whether the backend workflow is running with the same privacy rules and inputs as the page workflow?
Thanks again for the thorough testing and clear explanation — we appreciate the effort and are happy to keep digging with you.
Just checking in to see if you had a chance to review my previous message.
When you have a moment, could you please let us know how you plan to use the match scores (for example, lowest score only, threshold-based filtering, or sorting), and whether the backend workflow is running with the same inputs and privacy rules as the page workflow?
That will help us move forward and look into the backend behavior next.
Thanks again, and we’ll be happy to continue from there.
Re scoring - yes I get the idea “lowest score = best match“, I’d happily use the logic e.g. use the lowest score from the batch. But as the first screenshot shows (search term = email test), the lowest score is 0.177… which corresponds to “good email test“ company name, while what seems to be the perfect match (company name = “Email test“) is returned with 8.569… score.
So that’s what my first concern is about: that actually the perfect match doesn’t return the lowest score.
Re backend empty scores - yes I run both the test functionality above and backend wf’s with full admin rights. Although I didn’t take much time testing the backend issue, will come on to that after we sort the scoring thing.
You’re right: with Extended Search enabled, fuzzy scoring is token-based and weighted, so a compound value like “good email test” can sometimes score better than an exact match like “Email test”. In this mode, exact match doesn’t always guarantee the lowest score.
This is expected behavior rather than a bug.
To make exact matches win consistently, the usual options are:
Disable Extended Search
Add a quick exact-match check before applying fuzzy ranking
Or prioritize exact matches first, then sort the rest by score
If you’d like, you can also add us as collaborators to a minimal test version of your app (separate from production).
That would allow us to inspect the setup directly and verify the scoring behavior without touching your live app, which would be very helpful.
Let us know what approach you prefer, or feel free to share collaborator access when ready.
But the Extended Search in my examples is disabled (as seen on the screenshot above)
Oddly enough, I’ve just enabled it and it started giving more meaningful scores (lowest = best match), which goes in contrast to the explanation I think?
Thanks for your patience and for taking the time to share the detailed examples.
The key point here is that the scores you’re seeing are being displayed in scientific notation, which can be misleading at first glance. For example, a value like 8.56e-12 is not “8.56” — it actually means 0.00000000000856, which is extremely close to zero and therefore represents an almost perfect match.
In your case, the exact match (“Email test”) is, in fact, scoring better than results like 0.177; it just appears otherwise if the e-12 notation is overlooked. The same applies to values like 2.22e-16, which are also effectively zero.
So overall, the fuzzy search is behaving correctly: lower numeric values still mean better matches, and exact matches are returning the best (lowest) scores. If you plan to display these values, formatting them to fixed decimals can help avoid confusion.
If you’re open to it, we’d be happy to double-check everything directly in your setup.
You can add us as collaborators to a minimal test version of your app (separate from production), which would allow us to reproduce the behavior safely and confirm things end-to-end without touching your live app.
Could you let us know if that works for you, or if you’d prefer to proceed another way?
Thanks again for the thorough testing and clear communication — really appreciated.
Yeh overlooked the scientific notation part, thanks for pointing out, scores make sense now.
The backend issue is sorted too I think with disabling the Extended search option. It was quite counterintuitive it has to be turned off to actually get more results. Anyways, all good for now.
Many thanks for looking into it. In case you celebrate, warmest Christmas wishes!
Thanks so much for the update — really glad to hear everything’s making sense now and that disabling Extended search resolved the backend behavior.
Totally agree it can feel counterintuitive, and we appreciate you flagging that feedback.
If anything else comes up or you have questions down the line, feel free to reach out anytime. We’re always happy to help.
400+ Bubble Plugins
Native app builder for iOS & Android
No-code Development Services
