This topic is continuation of “Why is the whole workflow applied before it is started?”. I’m sorry for continuing in such a way but the Forum closes topics without mercy (I had hoped that 14 days are counted from the time of the last reply…)
@J805, thank you very much for the link! I was shocked after reading the aschofer’s answer. It’s very strange that nothing is said about this in the tutorial videos
So, do I understand correctly that workflows in the workflow tab are run in parallel and their steps are also run in parallel? Or are workflows in the workflow tab analyzed sequentially and only after selecting a concrete workflow (that satisfies conditions at the current moment of time) are the steps contained in the workflow launched in parallel?
@code-escapee, here is the screenshot of the workflows of interest (note that below I use distinct from the original post numeration of the workflows):
The first workflow (with count > 0) contains
So, as you can see, making changes to the Interaction and creating a new Conversation are the first and the second steps of the first workflow.
Then I run the app in the step-by-step debug mode. At some point I come across a moment of analysing of which workflow should be launched (it seems none of the workflows have been launched up to this moment, since no changes have been made to the database). The first workflow analysed is the second workflow listed above (with count = 0):
and it isn’t started correctly, since we have Interactions > 0 (and the condition is correctly red). BUT right after clicking on “Run next” in the debugger, it seems like both the steps from the first workflow (with count > 0) have already been applied! I make this conclusion because the evaluation of the expression in the condition shows no Interactions (empty result):
If I had a dime for all the hours I’ve spent trying to force Bubble to actually run my workflows step by step or for things to run when I expect them to, I’d be rich.
Best of luck here - I’ll be watching this thread with interest as I always do…
The worst part is “actual stepped workflows” isn’t on the Bubble roadmap.
I would suggest trying to run the workflow on the backend instead of the front end. Then it should go in order the way you need it to.
Sorry, what do you mean by that? Any manipulations with the database (searches, changes, creations) are run on the backend, and everything else is done on the frontend, isn’t it?
You can try, make changes to a thing as the first step and then create something if result of step 1 is empty.
It’s strange, but it’s simply not possible to check “if result of step 1 is empty” (I don’t see the option and can’t enter it manually). But I think it results in the same behaviour: the workflow will have finished (actually) before it has started (according to the debugger).
Do you have the backend workflows turned on in settings?
Wow, I haven’t known about that feature (no, I don’t have the backend workflows turned on since I haven’t known about them)… So, do you suggest to remake both workflows as backend workflows to see if I encounter the same behaviour?
Then just have 1 TinderPile swiped right event with no conditions. Instead run the necessary custom event with respective conditions.
Thank you for your suggestion! While this should help, is it a good practice? I’ve seen the recommendation to place conditions at the workflow level, i.e. check conditions in the workflow triggers, not in the actions inside workflows.
You are right. It is generally good practice to have for example click button (condition 1), click button (condition 2).
In your case there might be an issue with how the plugin works or perhaps both your conditions are true (or otherwise). Putting it into 1 workflow and into custom events will help you spot and/or workaround the issue. You can even add a terminate workflow action after the first trigger custom event, with the same conditions, as a safety measure.
This is how i usually troubleshoot race conditions. As another precaution i don’t use searches as part of WF conditions. Instead I’ll add an extra action or an event to store the result into a state and then use that state as conditions usually by sending it as a parameter in a custom event.
From what I’ve seen in my debugging and testing of multiple apps:
workflow actions will function in the order that you set them to except for api workflow scheduling which is triggered when the workflow is started. If you want the API workflow to trigger after a certain step then you need to use data from that step completing in the API workflow and then it will wait for that step to send it data.
The way I normally schedule API workflows to to add a “change data” step right before the workflow which I rename “trigger” and the data I am changing is whatever I map into the API workflow, that way the workflow waits until I want it to run.
Custom events can also be confusing. How these work is like a mini workflow within a workflow. So if you have step - step - custom event - step - step … then what happens is the workflow runs step 1 and 2, then it runs all the steps in the custom event until that custom event is completed (keeping in mind the API workflow issue above) and then it returns to the parent workflow and runs the remaining 2 steps.
The other issues I’ve noticed with workflows is particularly with backend workflows that are triggered from database changes these can trigger things to run that make it look like workflows are not processing the steps in order - but the issue is actually that multiple workflows are triggered at the same time.
For instance you might use a button to save changes to fields and on the button you trigger an api workflow but then also have a data trigger from one of the fields that were saved. Or the workflow may change fields that trigger other backend “when data changes” workflows. In general, and more so since the pricing model change, I’ve stripped out all of the “when data changes” triggers as they tend to be triggered too frequently. ie if a user changes a field 3 times it would trigger 3 times.
So, when I proceeded in the debugger, it showed that the “Interactions > 0” custom event was triggered but it also showed that its condition was not satisfied (it’s red and the evaluation shows empty results):
So, again, it looks like the workflow has already been finished (actually) even before it was started (according to the debugger), and the debugger simply follows the “correct” workflow after all the changes have been applied.
As another precaution i don’t use searches as part of WF conditions.
