How to make backend workflow actions run in parallel instead of sequence?

Questions
1

I basically have the opposite problem of most people, which is that I want my actions to run at the same time instead of in order. I’m not sure if this is because I’m using the same API call in subsequent actions, but the LLM calls will wait for the previous one to finish even though the subsequent one isn’t referencing the earlier one in any way.

LLM Call A –> LLM Call B –> LLM Call C –> Make changes to a thing (Using A, B, C)

My goal would be for all of these to run simultaneously, but what’s happening instead is A finishes, then B finishes, then C finishes.

Is this an API connector thing or just how actions run?

2

Just how it is unfortunately and I don’t see any easy solution.

3

Ok, I’m not the most experienced when it comes to workflows in Bubble…

but I was working on something last week that I think could be similar, and I was using AI to help figure it out.

What I ended up doing was having a frontend workflow trigger a backend workflow.

I think it would work in your situation also?

Added: My situation was to sign the user up. A frontend workflow ran to sign the user up, and then triggered a backend workflow that did 3 different things. I believe this setup would work in your situation also? Just throwing it out there

4

The question I have is why? Why do they need to run at the same time? If I know the why, I can tell you the how.

5

I’m already using a backend workflow. I’m talking about the order of those “3 different things."

It’s actually insane. Simple things like this is why Bubble is getting gapped by slop “automation” tools like n8n.

There is probably a way to do it by creating a bunch of different things with multiple fields and having a crazy WU-intensive database trigger setup but it’s just way too much complexity for something so simple and I’m not gonna waste my time with that.

@josh @nick.carroll I hope you guys actually go back to the core platform before it’s too late. Native mobile and AI has taken an enormous toll on the core product.

6

I was looking into this more after I posted…

and the way I suggested seems to absolutely work.

Not sure, but it seems like it does exactly what you want

7

Suppose you have the following:

Step 1 - LLM Call A
:down_arrow:
Step 2 - LLM Call B - (Uses Result of Step 1)
:down_arrow:
Step 3 - LLM Call C

:down_arrow:
Step 4 - LLM Call D - (Uses Result of Step 3)
:down_arrow:
Step 5 - Create a new thing (Uses Result of Steps 2 and 4)

LLM Call C will wait for Steps 1 and 2 to finish even though they’re irrelevant to Step 3.

8

I have it to schedule the workflow on a list

9

How do you compile the results in a single thing?

10

Ok, so, I can only tell you the instructions I was given.

I went back to my original discussion with AI and input your question, and asked for a follow-up from a user. As I said, I’m not an expert at workflows, but mine works the way you were describing. Anyway, to make things simple, here is what it said when I asked how to explain it to someone:

_____________________

That is an excellent follow-up question. This is the final and most critical step of the entire process.

Since each backend workflow runs independently, they don’t know when the others have finished. You need a way to have each one “report back” to a central “container.”

The solution is to use a single parent data thing that acts as a container for all the results.

Here is the step-by-step process you can share with them:

Step 1: Create a “Container” Data Type

  • First, in your Bubble database, create a new Data Type called something like LLM_Call_Batch.

  • This data type should have a field that is a list of the results you want to save. For example, you could have a field called results with the type text (list).

Step 2: The Front-End Workflow

This workflow now has two main actions:

  • Action 1: Create a new LLM_Call_Batch thing. This creates your central container.

  • Action 2: “Schedule API Workflow on a list.”

    • This is where the magic happens. When you schedule the process_llm_call workflow, you need to pass a new parameter to it: the unique ID of the LLM_Call_Batch thing you just created.

Step 3: The Backend Workflow

Now, your backend workflow (process_llm_call) has a new purpose. It will:

  • Receive a parameter for the prompt_text (as before).

  • Receive a new parameter for the parent_batch_id.

  • Action 1: Make the LLM API call.

  • Action 2: Make changes to a thing.

    • The “thing to change” will be the LLM_Call_Batch with the unique ID equal to the parent_batch_id you just received.

    • You will change the results list field on that container. Use the action results: add item and add the result of your LLM API call.

The Final Result

Now, each of the three backend workflows runs in parallel, but they are all programmed to independently find and update the same single LLM_Call_Batch thing in your database.

To get your final, compiled results, you just need to do a single search for that one LLM_Call_Batch thing. Its results list field will contain the answers from all three LLM calls.

____________

Don’t know if this will help, but I got mine to work through this method. I just changed it to your scenario to understand it.

11

Horrific complexity and also it’s a bad idea to have multiple separate workflows potentially editing the same thing at the same time since there is no atomicity in Bubble. Also a final processing step would need to occur, it wouldn’t be enough to just “collect” the results. So there would be no way of the “batch container” knowing that there were 3 results without using a database trigger. Then the DB trigger would have to have an aggregate search on it which would run every time a thing was created, resulting in insane WU costs.

Need #3 which was announced almost a year ago but crickets.

image
image989×384 58.3 KB

12

Ok, well, I’m sure you know more about workflows than I do…

but this was how I was instructed to set mine up. As I said, I had thought maybe your setup would be similar to mine. I was just trying to be helpful.

I did go back and add your last comment and got a follow-up on how to correct things…but we might just be going in circles here using AI.

Hopefully, someone with more experience will have an answer

13

Are you really just wanting to add to your database once, and that is the whole issue? Or is there something else I’m missing? All seems so simple to solve.

14

@randomanon , you would create the thing first –> run the steps in parallel (schedule on a list) –> update at the end of each workflow.

Conceptually, you would need to update something (i.e. store the data being created and referenced in each workflow), this could be some sort of custom memory/server/application, but it may as well be a Bubble thing.

If step 5 was creating a new thing combining the result of 2&4 (e..g LLM collating the information), you would run this at the end of whichever one finishes last or other custom trigger.

Edit: After re-reading the thread, i realise this is a rewrite of @senecadatabase ‘s suggestion :laughing:

15

Speed, each LLM call runs in sequence which could be many seconds for each

16

Sounds like custom triggers that return data. Each call that runs alone in each custom, the api calls that rely on each other are in same custom trigger. Series of actions is custom triggers with save to thing last with condition only when result of previous steps return data are not empty.

17

And how would you tell?

Nope, because then each batch has to wait for the earlier batches to finish.

I don’t think anyone other than @georgecollier understands what’s going on here.

18

If you’re keeping it in Bubble and you need atomicity in your parallel workflows, you can have each LLM response create/update their own record.
This can be one datatype with fields for each step with each one creating a record but in their individual fields. Alternatively 3 different datatypes. Or 1 datatype with a option set field to identify the LLM step.

Regardless they are all linked by the same pointer. Then you just merge the results. It achieves the same thing as:

Client side you can setup to trigger the final workflow after the merge, or do the merge clientside when all 3 records are available.

I do something similar for my batch report generations.

n8n is dope and does support scale. It’s just pricey to run on their cloud.

19

What you could do is create a bunch of different fields and say “When A is finished and B is finished and C is finished and D is finished,” schedule a workflow, but then you’d have to run a search for those things you created, as well as depend on the brittleness of a client side workflow (you’re also exposing how your backend workflow is being processed). The other alternative is a DB trigger but that’s not WU-efficient. Also you’re creating hundreds of temporary things for no reason. It’s just a lot of complexity for literally no reason, when actions should just run immediately unless they are waiting for the result of another action.

I’m pretty sure they can also parallelize API calls, right? I only mentioned them because they’re what’s blowing up on every social media platform, not Bubble.

I’m just so sick of the constant workarounds. “Bubble gives you the power of code without having to code!” except it’s death by a thousand workarounds which end up adding more complexity than regular code.

20

You don’t have to expose it. You can use a :count operator for client side triggering. A simple example would be a Group element as a number as a data source of a Search for Trigger_Datatype :count. All it returns is a number (unless my tests have been wrong all this time).

If you are tracking errors, you can have another group element with a data source. Then just constraint the 2 elements by the error field. A count of 1 will identify an error in the workflow.

Unfortunately that’s just the nature of Bubble today, I strongly believe we’ll get more layers of code translated to Bubblenese in the future.

It’s also why I write plugins and stack tech. Some workarounds are just not worth the effort (especially when it comes to troubleshooting) when you can do it with code and AI as a coding assistant. Often with better results.