Advanced guide: Creating Recursive Workflows and tracking their progress

Hey everyone,

I’ve been working on two advanced articles on Recursive Workflows that I hope some of you may find useful. It’s a topic that keeps popping up every now and then in my email and coaching sessions, so I thought I might share my thoughts here.

Article 1: How to set up Recursive Workflows (with different scenarios)
Article 2: How to track the progress of Recursive Workflows and visualize it on-screen

What we’re going to do in the second article is to set up progress tracking that we can visualize to our users in interesting ways like the example below:

Screen Cast 2021-04-25 at 3.26.20 PM

Happy reading, and let me know if you have questions or if you spot any mistakes :slight_smile:


@petter – this is fantastic, thank you for putting it together. Great guide and much needed.

1 Like

What a good idea for a guide on bubble. Recursion is a pain in the ass but it’s what I wanted to use when I first moved to bubble. So, this was one of the first projects I worked on and I will leave it here for others to check out.

The idea was that I had a repeating group and in each sale of the repeating group I wanted to be able to take those data and turn it into a single entry into the database. I was unaware of the orchestra plug-in in the beginning but I feel like this would apply for many recursive needs

1 Like

Thanks for the comments @ed727 and @jared.gibb.

I think recursive workflows are a bit overlooked especially for new Bubblers, since it’s not really a Bubble feature, but more of a method. Also it sounds pretty technical :slight_smile:

I find them incredibly useful (indispensable really), and have used them to reliably work on thousands of records with no issues. A couple of more points I wanted to add:

They can be faster than you think
Bubble’s documentation suggests five seconds between each cycle. While I understand their caution given the wide range of workflows that will be set up, I’d say this is an extremely careful approach. In my experience, you can set up as low as 0.1 seconds in-between the cycles and not really see that much difference on the capacity. It all depends on the workflow obviously, but do take the time to get some experience on this point, and you’ll learn to separate your workflows in a way that makes sense.

Set up a template
To save yourself some time setting these up, set up a template backend workflow that you can then work on. Of course, it’s quicker, but it will also make sure you set it up the same way every time. I got a question on Twitter about why I put the re-scheduling in the last step. Technically, it’s not really necessary to do it that way, but if I do it that way every time, I’ll know that the entire workflow will always be completed before the next cycle begins. It makes the dev process predictable.