It’s always been the case that backend workflows actions run immediately no matter their order in a front end workflow, or so I thought. I have a workflow that increments a custom state number by 1, and the schedule API workflow action is dependent on this number. Weirdly if I move the “schedule api workflow” action to the bottom of the workflow, it won’t run (because the number doesn’t meet the condition). But if I move it to the top of the workflow, it runs before the custom state increments.
Also, there is a slight “lag” or delay when the schedule api workflow action runs before the other steps. Is this new behavior? A bug?
Actions run as soon as all of their dependencies are available, though if you’re using Do a search for X rather than result of step Y, then the search may not have updated with the earlier value etc
So here’s the thing, there aren’t any dependencies on the “Schedule API workflow” action, just a condition related to a custom state. I was always told that under:
Clientside action A
Clientside action B
Clientside action C
Schedule API Workflow A
That 4 would immediately kick off no matter what. But that doesn’t seem to be the case. Instead, the actual order of actions is respected (just as they are for client side actions).
The state became a dependancy when it’s in the condition.
A lot of misunderstanding on this issue but it’s exactly what @georgecollier mentioned when it comes to backend workflows. So position doesn’t matter, just if it has all it needs. Including meeting conditions.
OK, just forget about the state for now because it’s irrelevant to what I’m talking about.
Clientside action A
Clientside action B
Clientside action C
Schedule API Workflow A
vs
Clientside action A
Schedule API Workflow A
Clientside action B
Clientside action C
Assume there are no conditions on any of the actions. I was under the assumption that Schedule API Workflow would fire first in both scenarios. This is not the case, and it respects the actual order of the client side operations.
It is the most relevant thing to understand to fix your issue. Clearly one of your client side actions is setting a state or doing something that is causing a state to become set to a value different than it was prior to those client side actions running and therefore is making it as you have discovered if the schedule backend workflow is step 2 you setup works, likely because the custom state value your backend workflow has as a condition to run or not is getting changed by the client side step B or C and so when you move your backend workflow action to step 4 you have already changed your custom state value in either client side action B or C.
So, DO NOT Increment your custom state number by 1 before you schedule your backend workflow with a condition based on the custom state value…or just remove the condition on the schedule backend workflow action and put it on the trigger, and create two triggers with two conditions based on custom state value with one not triggering the backend workflow OR put your setting of state actions into a custom trigger event.
I understand this, I know how to fix “the problem.” That’s not my point.
My point is that the action will run in the exact order of the flow, contrary to popular belief.
From the manual:
Backend workflows are triggered as soon as the workflow is triggered, independently from steps. For example, a “Schedule API Workflow” action will be triggered as soon as the workflow is triggered even if it is placed last in the workflow action sequence.
Either this was recently changed or it was never true.
From my experience it’s pretty much triggered ASAP. It could just that you perceive that there is no difference because your CS actions happen faster than your SAW gets triggered. Technically speaking it could actually take a while for the SAW to retrieve all the data it needs to run.
Have you tried to remove as many dependencies as possible for the SAW action to trigger in your test?
The set state action will run faster and complete before the backend workflow is triggered. This would be why there are multiple approaches to fixing the problem. Probably the easiest to understand would be using a Custom Event to Set the State of the Custom State so that it is ensured the Custom State does not get Set immediately.
Even though the actions will all run as soon as triggered, they do not run in order, and since the backend workflow trigger has the custom state value on it, it is likely bubble will force the issue of setting state first before they run the backend workflow trigger as Bubble often does this sort of thing when other actions are dependent on some value that may be altered by actions in the same series.
@randomanon if you check out the network request your browser makes for this workflow it’ll probably be enlightening and help think about this problem (you’ll see what I mean if you look at the input payload and the response data)
Hmm maybe. The only other possibility I can think of is that if you have a condition based on a custom state, then the schedule workflow action will wait until previous actions affecting the state have fired, but I’ve never heard of anything like that. I also had a pause action in the workflows before the schedule api workflow action. But I think it’s just what you’re saying. I guess that’s consistent with the Bubble documentation that says “actions fire in sequence but they don’t wait until the previous action is finished [unless you use “result of” or custom events].”
Sorry I thought you’d understand the use of ‘likely’…below is a run down on how it is used in sentences courtesy of ChatGPT.
The word likely is primarily an adjective, meaning “probable” or “having a high probability” (e.g. It’s likely that she’ll come.). In grammar it’s often called an epistemic (modal) adjective because it expresses the speaker’s judgment about likelihood.
In more informal or American usage, likely also functions as an adverb—a sentence‐level or “modal” adverb of probability—where it modifies the whole clause (e.g. They’ll likely arrive late).
So, depending on context, likely belongs to the class of:
Adjectives (predicative: That outcome is likely.; with infinitive: He’s likely to win.)
Modal/epistemic adverbs (informal: We’ll likely leave at noon.)
Both uses fall under the broader category of modality—words that hedge or qualify how certain we are about what we’re saying.
