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

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: https://beegle.app/version-test/list-scheduler-test

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

Hi, did you find a solution for sending hundreds of emails without timing out, I’m facing the same problem. Thanks

From what I understand, you have to schedule an API workflow that then triggers the emails.
So what I’m doing is triggering the API on the page and then everything happens in the backend with a recursive workflow (it triggers itself at the end) that goes through all my users and sends them one email. And I’ve basically given all of them a number and the recursive workflow goes through each of them (it acts as a kind of loop).

Hope this helps

Great, I see it now, thanks @tart2000design !
I assume that you have more than 100 recipients, so how did you solve the 100-free-email daily limit bubble/SendGrid has?
Did you just go for a paid plan (SendGrid, Postmark) or you found a free service for mass email?

Yes, I have around 3000 users rn. I’m using a paid plan on Sendgrid. But if you’re not in a hurry for your users to receive their emails, you could use the recursion to add time, either by adding 24h/100 between each or by ‘scheduling +1 day if user n° modulo 100 is 0’…

Thank you @tart2000design this is a very good suggestion.

1 Like