Optimization - How it works? - Reuse Search result on workflow

Ever once in a while I spend some time trying to figure out what is the most optimized way to achieve something at Bubble. But this one is a little bit tricky:

Is Bubble optimized enough to reuse a “Do search for” result used multiple times in workflow?


If I have three steps in my workflow and each of they rely on the same “Do Search for” as conditional and as input:

Step 1) Create a Thing / only when “Do Search for xxxx:count = 0”
Step 2) Make change to Do Search for xxxx:first-item / only when “Do Search for xxxx:count = 1”
Step 3) Custom Event (with “Do Search for xxxx” result as input) / only when “Do Search for xxxx:count > 1”

The same query was used multiple times. Am I overloading Bubble backend? If so, the solution for that would be creating a Custom Event that would receive the result of “Do search for xxxx” as input and will treat it as variable?


Yes, I’m quite certain that Bubble does optimize and cache some calls. So much so that there’s a known work-around for API calls where you add the unix timestamp as query parameter as to force Bubble into seeing this as a new call.

So, if I were you I wouldn’t try to optimize it now. Just go on building the flow as you believe it should be done. Afterwards, take a look at the logs and see if it’s affecting it.

1 Like

Yes, @rico.trevisan is correct, the results of a Search for... are cached locally. Once a specific Thing has been fetched from the database Bubble generally need not fetch it again. Similarly, fields on a Thing once retrieved are also cached.

So, lets say you Do a Search for Things :items to 100 and then later Do a Search for Things :items to 200. That second search does not need to fetch the first 100 items.

The above being said, having to construct some search expression over and over is sort of painful (even though you can copy expressions) and one might want to store the results of a search in a custom state (or any other plugin that acts like a custom state, like List Shifter, or Floppy, or whatnot) to make referencing it easier. (And yes, this is the Bubble equivalent of storing those results in a variable.)


Wow this is an absolute death trap. I was working on setting up a multi-step API workflow with ChatGPT. It looks like you can’t use the Search for: Messages function multiple times in the same workflow (if you’re adding messages as you go).

Glad I found this thread! Life saver. I’m going to have to set up a new API workflow for each step in the ChatGPT thread.

1 Like

Custom event is probably the way to go, no? Create a custom event - all it does is return a list of Messages that is your Search for messages. Call it in the workflow, and reference it in other steps (Result of step X’s Messages) where you would normally Do a search for Messages.

What about using as step 1 - make change to a list of things (this works without actually choosing any field to change) and then refer to the result of this first step ?

Yeah, that works too, might use more WU though depending on if Bubble will run the make changes call even if no data is modified

Custom events costs less WU and are generally more efficient. I also find them more organised and tidy.

Check out @adamhholmes great writeup.


The last time I tested this (which was just after WUs were introduced), I’m sure they were charging WUs for changing each item in the ‘Make Changes To a List of Things’ action, even if no changes were actually made.

However, I just tested this again, and it no longer seems to be the case.

But… it still used more than 3 times the WUs than the search alone did (e.g. just setting a custom state, or returning the list from a Custom Event).

So I still wouldn’t recommend using this method, as it’s way more costly (more than 3 times more in my simple test) - although I’ve got no idea where the additional WU cost is coming from in this case.