Workflows run IMMEDIATELY in Slow Mode and Step-by-Step BUT CRAWL in Normal Mode

Hi, there. Firstly, thanks for all your contributions. I’m a newbie and this forum has already been invaluable.

I’m having lots of speed and responsiveness issues with my Cash and Account Balance Forecasting App that I’m developing. I’m trying and testing lots of different ways to approach the problem of forecasting out on a daily, weekly, monthly, yearly basis.

None, so far seem to solve the speed issue. But I’ve noticed a potential issue. I’ve reported it as a bug but wanted to raise it here to check if anyone else has the same problem and has a workaround.

In short, it’s as the title says, in Normal Mode (in test NOT live - I haven’t tried to run a live yet, the app isn’t there yet), the simple workflow crawls along whereas in Step by Step or Slow mode it’s almost instantaneous.

On click, I have a Change List of Things. The records that are changed in another thing (rather than having to create them with an API I have a scratch Thing to process forecast dates) are then copied back to a list field (it’s a series of dates). The issue I’m having is that when I let this run in normal workflow debugger mode it crawls along, takes minutes to process. When I use step-by-step and click the next step quickly it performs the actions almost instantly - as quickly as I can press next step. When in slow mode it goes through the motions and updates the things in a few seconds if that. But when in normal mode it crawls along and sometimes doesn’t appear to finish.

Not sure what the problem is. Has anyone had similar and solved it.

Thanks in advance! Richard.

P.S. Have tried different browsers and windows (currently on Mac OS High Sierra) operating systems (under VMWare) and no difference to the above. Also tried a Live version and the same applies.

Hi @richardconner

Don’t know if you are still having this problem but I started having the exact same problem since yesterday and filed a bug but still awaiting a satisfactory response. I use the “filtered” method & “formatted as text” method to select what to store in a “Make changes to thing” action. The action takes minutes to process in Normal mode but processes instantly in Slow and Step-by-Step mode. Did you get a fix from the Bubble team?

@emmanuel Any fixes?

Based on what I’ve observed, I shared some thoughts on what may be causing this a few months back on a similar post. See link below.

At a high level, when you’re running step-by-step mode, the workflows (I believe) have a bit more time to catch up with themselves (ie. when you have text manipulations or you’re updating custom states within a workflow, which you later reference). But in run mode, it ends up rushing through and waiting for information that isn’t yet ready.

Hi, Naj. Generally the solution to this problem was to ensure that my database objects had link type fields so you can move between the tables quickly using list fields of whichever type. Second avoid searches like the plague.

For good or bad I rarely use the debugger now.

But what I found was that sometimes you can do things client / user side through browser triggered workflows and it will populate values that you can see in RG’s and Charts and then the values will drop away and revert back to the previous values. It took me quite some time to realise that the app was timing out due to the operation (i.e. workflow was taking >5 mins to process) even though it starts to show all the data! How it can show the updated data (instantly) and then needs to revert because it’s too busy (how did it get the results in the first place?) is beyond me!

Hope that helps.

Use connecting object thing type fields to connect database objects / things.
Use list fields of these types / normally on User or other things depending on your use case.
Avoid Do a Search for especially stacked / nested Do a Search for.


In this situation, the server’s database is considered a “source of truth” and the client’s sub-copy of the database which had changes that the server didn’t make, is refreshed to match the server’s database.

Thank you Mishav. Very helpful to know.