Change a Thing with Searchbox input result

I 'm new at Bubble! Cant figure out how to save the search input form’s result as either the chosen result that exists in the search or the typed result if it doesnt exist in the search. I am trying to do this in a workflow when the submit button is clicked. I have the search input set to allow entries not in the list while typing. I need this to change a field on a user if it’s typed in or selected from the search and can’t seem to make it work? Any help would be appreciated!

You can follow one of two approaches:

1 - As the search box can allow entries that do not exist in the source list you would have to create 2 different WFs, 1 for when the entry exists in the source list (value is not empty) and another when the entry is a new value (typed text);

2 - You can use a custom state to store the value as text, in both cases, and then when saving, use the custom state as the value to be saved.

1 Like


THANK YOU! This worked GREAT!!! I’m Searching for Company Names on Users. The result is a return that includes duplicates looking like this… Jones Express and Jones Express (1). I cant figure out how to eliminate the duplicate from the search options. Can this be done?

You can try use the plugin Searchbox: no duplicate Plugin | Bubble (I personally never used it)

So far, what I’ve had to do in cases like this is something like create a list that saves only the product names (no duplicates), if you already have a list, you could open it in Google Sheets and use the function “=unique (range)” to generate a list of unique products and then import it into the newly created list.

So, whenever you are going to save a new product in the original list (the one that contains all the product information), also make the product be saved in the product list (unique names) only if that product does not already exist in the list.

NOTE: The options listed in the search box as “Item, Item (1), Item (2), etc” appear like this because each one refers to a “unique” record in the DB, having only the same “label”, therefore, in this new list the data would be of the text type, and it would not be possible to link them directly to other data in the original list, except by comparing this textual value. It is up to you to check what would be the possible calls and searches made later with this data and use the most appropriate context of constraints.

Hi Newed,
Could you please develop the first point? What do you mean by two workflows? How do you connect them in a unique action like “button clicked”?
Thanks a lot

Of course, here is an example and additional information.



1 Like

Thanks a lot for your help Newed. Now I use 2 different workflows and it works (partly) : I can use the typed text format in the other workflow. This last WF is a custom event because I want to respect my sequence.

Here is the link of the view mode of our app

Here is the main WF

And the custom event one

So basically I want to create a bottle of wine with different characteristics that are stored as other data tables.
So in the first 5 steps, I store those characteristics ONLY if they are unique, then I create the bottle in step 6 but with the searchbox’s values (sometimes empty).
Then if those characteristics were unique I make change to the bottle’s ones with the 5 first results (steps 7-11).
Then I want to use the typed text and apply it for this LAST bottle created thanks to the custom event which allows me to use the search box’s typed text. So I make change to those bottle’s things (last item created).
When I do that and look at the step by step debugger, it is supposed to work but when I look at the bottle in my database (which the custom event effectively called and modified) those modifications are not done and those values stay empty.

Here is a view of the debugger which shows that the last bottle created sees its specific value modified

I really don’t get it…
Could you please have a look. Sorry to take your time…

Okay, I still don’t fully understand all the steps in this WF, but here we go.

I noticed that there are many steps in your workflow, each with its own conditions.

First, I believe that in step 3 and 4, you also need to save the result of previous actions. For example, in step 2 you create “Country”, in step 3 you create “Region”, which supposedly should contain a field linked to “Country”, which would be the result of the previous step, and the field “Region” in the format text, which would be the value of the input. In this case you have not set the “Country” to be saved. The same happens in step 4 with the fields “Country” and “Region”, which should be obtained from the result of the previous steps.

From what I understand, in steps 1 to 5, you are getting and saving input data, when this data does not yet exist in your tables (typed text). In step 6 you are creating the “thing” itself (Bottle), and in steps 7 to 11 you are making modifications to the created thing if the input values are not empty (they exist in the tables).

Well then. Because of that structure you’re trying to handle and the amount of actions. I believe you should
try another approach that might make all of this easier.

You could store the data for each input in a custom state. I know this would increase the amount of WF, but it would be more WFs with less actions in each one. This way, when an input was changed, its value would be stored in that state. Here you would need to work with the two possibilities, "value is not empty" and "typed text is not empty" or any other condition using these two input states that results in the same approach. This way, the final stored value would be a text for both cases.

Now you would have a single reference to the values when creating the “Bottle”, which could be the first step of the WF. And the other steps would just be to update the other tables with new values if they don’t already exist in them, and for that you could refer to the results of step 1 (where you saved the “Bottle”) and insert some conditional like "Do a search for "table":count < 1" to check if it doesn’t already exist in the table, in which case WU would be consumed. Another way would be to check the content of the input itself, after all, if "value is not empty" means that the value already exists in the table and therefore, there’s no reason to create a new thing in that table, otherwise the value doesn’t exist in the table yet (I hope you understand). Theoretically, this last verification approach would not consume WU.

There are some problems that could arise over time in these “auxiliary” tables since they can receive any value entered by the user, which could be duplicate values, but with a change in some character, way of writing (uppercase, lowercase and capitalized ), unnecessary spacing at the beginning or end. To work around some of these problems, when storing data in custom states, you can format and modify them using operators (they can be used together):

:capitalized words
Returns the text with the first letter of each word capitalized. For example, ‘this is bob’ becomes ‘This Is Bob.’

Returns the text with all letters capitalized. For example, ‘helLo’ becomes ‘HELLO.’

Returns the text with all lowercase letters. For example, ‘HelLo’ becomes ‘hello.’

Removes the spaces at the beginning and end of the text. For example, ’ fd ’ becomes ‘fd.’

Try this approach and let me know if any questions arise. :grinning::call_me_hand:

Thanks a lot for your time Newed I really appreciate it!

Here are some complementary questions related to your message :smiley:

  • I thought that my first 5 steps were independent and that each focussed on the characteristics they are working on. I also thought that they effectively fill the right tables.

  • I have never used custom states yet. I will try to work with that with the resources available on internet but last time it didn’t work
    I just tried to affect the custom state value to searchbox but it did not work :smiley:

  • this last point might linked to fact that you mentioned saying that you need more work flows with custom states. I had no idea about that, why is that so?

  • Alas for the searchboxes, when I type a text in those and with the perfectly matching letters BUT without clicking on the data suggested by the searchbox, its “'s value” is empty and its “'s types text” is not empty

  • one last question : you suggested with the custom states to first create the bottle and then complete the characteristics’ tables. But the BOTTLE is linked to those tables, isn’t it a problem to modify those table after creating the BOTTLE item? I mean by that that due the fact that BOTTLE is linked to them, shouldn’t I first fill those characteristics’ table?
    THanks again

I tried a new workflow with the custom states that you advised. It seems to work according to the step by step debugger Newer. Thanks
But for characteristics of the bottle that I get with the help of the custom states, I still have empty fields returned… Could you please have a look? It seems that the steps 4 to 8 don’t work.
Here Is the new workflow:

They are dependent in a way, but come on.

The “Bottle” thing is the main thing that has a bunch of data, pretty much all of it linked to other things (other tables). Therefore, changing the data in other tables directly reflects the data related to all “Bottle” that have this link.

But besides “Bottle”, other tables have links between them. This is the case for “Region” and “Country”.

“Country” only has a text type field, so when creating a new “Country”, you only need a text type data. “Region” has text data and data associated with a “Country”. Therefore, when creating a new “Region” you need both text data to identify the “Region” and a “Country” to define which “Country” it belongs to.

If in the actions of a WF you are creating “Country” in step 2 (for example) and in step 3 you are creating “Region”, you can use the result of step 2 to fill in the “Country” field of “Region” and the value obtained (from elsewhere, custom state, input, etc.) to populate the “Region” text field. If you don’t define the “Country” field to be targeted in “Region”, it will be empty and will cause problems in possible later filters.

There is no secret to using custom states. Both in the forum and in YT videos you can learn a lot about it, its applications, indications for use, etc. It’s worth trying to understand how they work, when to use them, it’s not difficult.

Basically because at first I had the idea of initializing a WF with each changed value of each input, but you defined these state assignments in the click event, in two custom WF, I checked the debug and it’s working, so it’s ok. It could even be grouped in the same (but it would turn into a mess).

Yes, this is a problem that could be avoided by checking the input value (or after formatting) with the table values, but it would generate WU consumption. After the new pricing model, everything terrifies us when we think it can consume WU.

Yes, you are correct. I didn’t remember the fact that in some cases, new records will need to be created in the auxiliary tables and that they will be linked to the main table.

Thanks again for your help.
Now I get your point for the links between country/region etc. It is fixed.

What I still don’t understand in this workflow

is that I still can’t get steps 9 to 13 to work. The things stay empty and I can’t MAKE CHANGES to it. But the step by step debugger show that it seems to work. Really weird.

I’ll keep digging.
Again thanks a lot

Problem solved in private message with editor access. But posting the solution here in case someone, someday, comes across a similar problem.

Well, thinking about your case, which in a way is a specific use case using searchbox, since you are not only using the searchbox to search for existing values ​​in the database, but to create new things when the values ​​are inserted in the searchbox do not yet exist in the database, in a way that they are not duplicated. Also, some of these things are not just text, they are data types related to other data types, so whether you create new things or use existing things, you still need to use values ​​from those things to create the main thing “Bottle” , which is related to all the others.

Therefore, we need to create the auxiliary things, if they don’t already exist in the database, before creating the main thing. With these things newly created or already existing in the database, we need to store a reference to each one of them so that we can use them when creating the main thing, this avoids the need to do searches to retrieve their values.

Therefore, the custom states that were previously defined only as texts, are now defined as the auxiliary things themselves, each one associated with a specific thing (I defined the custom states in the main group, “Group A” that contains all the inputs .

As for the two custom WFs, one of them creates new things when they don’t exist in the database and then sends that thing as a value for the corresponding custom state. The second custom WF just sends the value of each thing to its proper custom states, when they already exist in the database.

Finally, the main WF executes the two custom WF and then creates the main thing using the data stored in the custom states, resetting the value of these custom states at the end of the process.

Again Thanks a lot Newed You have been of HUGE help!

1 Like