Forum Academy Marketplace Showcase Pricing Features

[New Feature] Scheduling API workflows can now be done recursively

I confirm the process may stop without any reason with recursive API workflows. Check the logs, you may find some “Workflow erros”
This can happen when the app gets too busy

1 Like

Yep, another workflow randomly stopped. No error logs. Just stops. @josh , any thoughts on this. Looks like others like @nicolas_dap also experience the same issue of recursive workflows failing randomly. The app was not busy at the time in any way and server capacity has not maxed out.

1 Like

It would be nice to have a bubble answer to this

So let’s say I want to send daily email reminders of pending task, I will have to start/send the first email batch and then the following emails will be automatically scheduled with no manual intervention? And what about the workflow limit on personal plans?

1 Like

Yes. But you need to be considering the “limit”, so just don’t try to send 1000’s of emails (i.e. run too many workflows)… be reasonable :slight_smile:

1 Like

well that is really freakn awesome … yes yes and YES!

I’d suggest not to get overexcited as with Bubble “looping” has limitations, which are quite easy to reach :frowning:

In other words, build loops part by part and test them :slight_smile:

well i can dream :slight_smile:

1 Like

Hello dear community

I have an event App. I am considering using recursive workflow to let user create recurring events : meaning they can create a first event, and then with recursive workflow I’d like to « duplicate » the event let say : every Tuesday, every week, etc, for the next two month for examples.
And then having some rules to check if the event is create for the next months, if yes nothing happen, if no create it automatically.

I have two questions :

  1. Is this a good solution ? What limits do you see.
  2. I think it will do what I need, My main concern is about The number of data it will process and create.
    I could have for example 100 people creating 3 events a week, each of them contain a certain number of datas… so Roughly 300 things a week, 1200 or more a months…

What are your thoughts ?

More details here if needed to help Planning recurring events : What could be the best option?

@josh @NigelG

Thanks a lot

Could this be used to have a workflow run for a few seconds?

For example? What if I wanted to increment a thing’s number in my database continuously for a minute before it stops?

So I use “call api on a list” and “recursive workflows” both.

While I understand recursive workflows are more reliable etc. as mentioned in original post, I do find “call api on a list” more easy to work with. I can simply call it with one action, instead of having to put logic of calling recursively and doing a double check that conditions are set correctly. Also, I can just build one API and use it for individual item or a list as per need. In case of recursive, I need to create a separate API for one item and list.

So, I prefer using “call api on list” wherever possible.

However, I want to make sure I am not using it wherever it is not advisable to use it.

Can we please list cases where one should not use “call api on list”?

Can I call api on list if I am not bothered about sequence of things or time it takes or synchronisation?

Does this decision depend heavily on number of items in the list? Can I call API on list if the list has 1000 items as long as I am not bothered about sequence, synchronicity, time it takes etc, or knowing when it is done?


Recursiveness is used mostly when different changes are needed on the iteration.

Schedule on a list makes the same change to all iterations

I am not sure if I follow what you are saying. How does the “same change” and “different change” come into picture? It is just a method of calling a workflow. I can do same or different thing in the workflow. That is totally independent of how it is called upon?

Also, my question is more on the logistical differences in the two methods. As you can see, in the original post itself it is mentioned that calling on a list is good for small number of items, and for larger set, recursion should be used. I am just looking to refine those guidelines.


Try doing the following with “schedule on a list” where your backend workflow has only one action:

  • You have three empty entries in your dB for “thing” which has one text field called “color”
  • Your backend workflow has only one action that changes the field color
  • Try changing each entry so that the first entry can have the text “yellow”, the second entry the color “blue”, and the third entry the color “red”


I’m curious if it would work. I’m not sure the results will be consistent each time you run it.

  1. WorkflowTimerStart
  2. Action: Change some DB item, save the current date/time as savedTime.
  3. Action: schedule WorkflowTimerRecursive

And then:

  1. WorkflowTimerRecursive
  2. Action: increment Number
  3. Action: schedule WorkflowTimerRecursive unless it’s savedTime +1 minute.

@cmarchan I would do it by having a serial number in all my entries and in the action assign colour based on their sequence number. I am not able to see why would it differ in scheduling on a list and in recursive. I would do the same in case of recursive too. I know that recursive can maintain the sequence, but underlying action is same, right?

Also, it would be nice if you could also comment on the all the logistical aspects of scheduling on list vs recursive. You have commented on one aspect which is about “same change” vs “different change”. Thanks for that. But it would be good to also have an exhaustive compilation of points of differences between the two options. It would be kind of extension of what is mentioned in original post.

Hello @mghatiya

What you kindly describe would not work. Try it and find out for yourself. :grimacing:. Would love to be proven wrong! :grinning:

Here, a suggestion I provided a while back on when to use the different backend flows.


Here’s a demo I have created for your kind perusal: Your Bubble app

You can reset the colour using Reset button, and assign the colours using Assign buttons.

Here’s how workflows look like.

Here’s how the data structure looks like:

It meets all the conditions that you had stated.

My recursive workflow keeps stopping at exactly 100 iterations. This can’t be a coincidence and my capacity is not even close to maxed out. Anyone experienced this problem before?

Could this be used for sending an email to all my users?
At the moment, I’m using ‘API workflow on a list’ and it times out. So I have no way of knowing who received an email or not :confused:
Could you explain how I would do that?
Thank you