Hello.
I want to create a workflow where, if an input value is already registered, an alert is shown, and if it is not registered, the value is added. However, in cases where the value is not registered, the “Create a new thing” action fires before the :count check, so both the registration happens and the alert is shown—this is the issue I’m experiencing.
I believe this is similar to the issue discussed here:
According to advice from the Bubble.io Bug Report chatbot, it suggested saving the count value to the database and referencing that value via “Result of Step” as a condition for “Create a new thing.” Is this… for real?
I’ve summarized my issue in a video. The Custom Event refers to the return value of the previous CE.
hi @dev.otofu ,
Well the behaviour you showed in the video is normal because the “Button Check & Save” once it is clicked, it triggers a workflow not a custom event and in workflows the steps are triggered in order but each step doesn’t wait for the previous one to finish so in your case, “Create a new thing” is executed before your custom state values are set.
In order to solve this, you need to guarantee the order of execution as follows:
1 - Use a custom event instead of workflow. Custom events should execute in the right order always. So you’ll need to transfer exactly your current workflow steps to the newly created custom event.
2 - in your “Button Check & Save” workflow, call the custom event you created. so your workflow should have only 1 step “Trigger a custom event”
3 - Test again as this should work correctly.
Hello @ahmed.elkaffas ,
Thank you very much for your kind reply. I tried your suggestions and created a video to demonstrate the results.
1 & 2 – As you advised, I set up the workflow triggered by the “Button Check & Save” so that it includes only one “Trigger a custom event” action.
However, the result remains the same: the “Create a new thing” action is still being executed before anything else. Do you think I have implemented it exactly as you described?
Lastly, in the video, I used the word “misfired,” but considering that Bubble workflows are not guaranteed to execute strictly in order, I realize now that it may not have been the most accurate term. Still, I would really like to find a way to ensure that the count action is executed first and controls the sequence.
If you have any further advice or see something I might have missed, I would appreciate your input.
I conducted the above test using the “Mobile app” and checked the results with the “Web debugger” (as shown in the video). However, this may have been a mistake.
When I tested it with Bubble Go, I found that registration and the alert did not fire simultaneously, and everything worked as expected. It seems that both the blue button created with WF and the green button created with CE are functioning properly. Sorry for the mess.
I’m planning to run the same experiment using the Web Builder as well.
Not correct. Client side actions do follow their sequence in a WF. Server side actions will immediately trigger when they have all required data and meet their conditions regardless of their position in a WF. Hence a server side action with conditions that require the result of a previous action will wait.
This works because Custom Events are treated as client side actions so will adhere to their sequence.
The video is talking about what I said. Server-side actions will trigger as soon as they get the data they need to run. Client-side actions will follow their sequence in a workflow.
Normal client-side actions start and end fast enough one after another to look like they are not in sequence. In reality, they do wait for other client-side actions to finish before triggering. If the opposite was true then, many apps will break. You can test this by sequencing a series of client-side actions.
Steps 1, 3 & 4 are server-side actions and will trigger as soon as they have all the data they need.
Step 2 is a client side action and will trigger as soon as Step 1 is triggered.
While it is correct that Step 2 it will not wait for Step 1, it is only because there are no conditions referring to Step 1 attached to it. If you put a condition like “Result of Step 1 is not empty”, it will wait for Step 1 to “finish”.
This is more of a technical decision from Bubble and related to just how code works. One action will not wait for another action to finish if there is nothing to “wait” for.
Most client-side actions will run in their sequence because client-side code can be tracked client-side. It can “signal” the workflow that it’s done doing its thing. Server-side actions need to return values in order to “signal” that it has finished what it wanted to do.
You can picture SSAs with no values to return, as being removed from the sequence as soon as it triggers.
By default, Bubble does not send the results of most server-side actions back to the workflow. Any condition in subsequent actions that refers to its’ result will force Bubble to return the data (these are some of the sources of “individual requests” in your WU log).
TL;DR:
Server-side actions run as soon as they have the data they need — they don’t wait for other steps.
Client-side actions start and end fast but they do respect the sequence.
Step 2 (client-side) doesn’t wait for Step 1 (server-side) because there’s no condition linking them.
If you add a condition like “Result of Step 1 is not empty,” Bubble will force Step 2 to wait.
Bubble only makes steps “wait” if there’s a reason (i.e., data dependency).
Referencing a server-side result forces Bubble to return data = costs WU. Not a big enough amount to fret about though.
