So I have “sign the user up” and a “make changes to a thing” actions that are giving me a LOT of problems today.
They are in the standard bubble user signup workflow.
After the user presses “OK” to sign up, it checks to see if they are in a scammer database, then it either opens a popup and sends them on their way (if found in the DB) or it continues to sign them up if they are not in the scammer DB.
Problem: It’s executing out of order and signing them up before it can check if they are in the scammer DB.
I used the method I found on here: “Results of Step 1” type of logic on the Actions that need to happen such as the Popup that kicks the user out. But it doesn’t work. It signs the user up anyway.
I even went so far as to create a Custom Event and I moved the user signup down there and NOTHING. It traverses the workflow in parallel and goes down into the Custom Event and signs the user up even though it’s both controlled by “Results of Step 1” logic AND being way down in a Custom Event.
How can I get around this??
How can I control the order of these actions?
Any ideas? I’m running out of things to try.
Thanks!
PS: It’s such a simple concept: If userdata is in the Scammer DB, fire a popup and close. If userdata is not in Scammer DB, sign the user up. But in Bubble? It’s like I’m calculating the mass of the Higgs Boson
If you’re using ‘Current User’ to check if they’re in the scammer database, nothing would happen as they’re not logged in at this time
Instead, try using ‘Email inputs value’ to check whether the email exists in the scammer database
Thanks. Good Point. I’ve tried a bunch of things, but that one isn’t the issue.
I’m doing “Do a Search For” to scan the scammer DB from the inputs they fill out on the login screen. When that hits positive, I flag something and take action based on that flag.
I’m trying to avoid a “Do a Search For” on every single action in the workflow since each action would have 2 “Do a Search For” items in it and the WUs would be insane. But maybe that’s why it works the way it does? More revenue for Bubble?
And it’s literally doing the actions out of order.
It doesn’t hit the “Sign the User Up” action at all in Step-By-Step in debug_mode, but you can watch the user appear in the User DB anyway.
The new user appears on the first or second step of a 12 step workflow (counting the steps in the Custom Event)
It’s maddening when you are used to regular programming.
There are workarounds that I read about on here like using “Results of step 1” type logic so it has to wait for Step 1 before it can create the user but nope. Creates the user anyway
Sure. I don’t think it’ll be very helpful though. Just standard stuff.
In this latest attempt, I created a “User Signing Up” Database to try to control the execution order. I start the workflow by creating an entry in this new database, then scanning to see if the user signing up is in the Scammer DB. It does that on the second step, setting a flag in the Users Signing Up database. If the flag is set, it shows the popup and terminates the workflow.
So doing step-by-step in the debugger, it fills in the real User DB with the info on step 1 or 2 of the first screenshot, even though the Sign The User Up action is down in the Custom Event. Makes no sense whatsoever. It’s a known flaw/feature. There are posts on this forum talking about it. I tried what they suggested to control the order of execution of the actions (results of step 1 type stuff, and locking away the problem action in a Custom Event) and it didn’t work.
I was having lunch so I didn’t get a chance to just abandon the whole thing and let the user signup then catch them after they sign up yet. I was just hoping to have it be more elegant that that and catch them before they sign up
best to use custom events here to compartmentalize each group of actions
custom events fire in sequence in a workflow (they wait for all steps before them to be completed before starting, then the steps after them wait for all the steps in the custom event to be completed before the parent workflow continues)
this is actualy not always the case unfortunately. CE fire in order BUT Bubble sometimes decides that one takes too long and fires the next.
I had this issues while trying to create a report in a temporary table (go search all transactions from date a to date b, the for each stone size you find, search for all transactions, write each of them in a table, and after write a total line and an empty line, then loop to the next one)… I found no other way than making sure events can start in whatever order they wanted…
If anyone has the magic solution for asynchronus WF I’d love to hear it… I tried loops waiting for something to happen… not working, I tried to set up a special status table, not working.
I would create a custom event, with a return value. Manually set the return value to a non-falsy value (e.g. >0 or true) if they are not a scammer (this is important, since a falsy value will be the default, and in many cases will allow the undesirable behaviour to occur, as I learned the hard way!). When they click the signup button, the first action is to call that custom event. Your subsequent actions following this custom event, such as signing up the user need to have a “Only when” conditional on each of them that looks for the positive result from your custom event. I have found that method works flawlessly, at least in my case.
I fought for months and months on the “async” behaviour of workflows, which remains completely unintuitive in bubble. If you don’t understand that bubble by default will trigger most actions at the same time, especially “costly” ones like “Do a search for” - you can get very confused, especially since the debugger typically suggests it is synchronous! Lesson learned: don’t trust the debugger. You will not believe how long it took me to realise these two lessons.
In my app it was a lot more complex though, as I am also synchronising with a separate DB via a client-side plugin, so I spent a TON of time trying to work out what was going on (even went so far as debugging the bubble JS!) - and ended up forking a plugin in my case due to this irritating behaviour so I could create some plugin-triggered events to handle this complexity. Benefit is though - it is rock solid now and I’ve learned a ton about building plugins!
So THAT is how you can force it to be synchronous!
I read about using the Custom Events to do it, but didn’t take it this extra step to literally force them to wait for a return value.
Great idea. It has to work.
I created a convoluted “check them after they sign up and see the main page” type of process that isn’t working quite right yet, so I may delete that and go back and try it the way your are describing.
It’ll be way more elegant and save WUs
This is a really useful tip. I hope it helps some people in the future who find this thread.
I’ll come back and report if this works after trying it today
Put the actions you want to control into custom events. One action or very small group of actions in each event.
Require parameters and return values on each Custom Event.
Use “Results of Step 1” type logic in the main workflow to make each later Custom Event trigger from the result of an earlier Custom Event. That way it can’t start until the previous one is finished.
Works flawlessly now. Kicks scammers out before they are entered into the user database and tracks their entered info as it should.
Thanks SO MUCH. It was very confusing to have everything running in parallel and I never knew it did.
PS: This also saves on SendGrid emails getting shot off for no reason to verify email addresses since it never does a “sign the user up” if it’s a scammer
It’s probably the biggest hurdle in understanding workflows in bubble - and probably the LEAST intuitive aspect of the entire platform, if I’m honest - since the editor (even the “reworked” one) clearly suggests the workflows are sequential and never distinguishes just how much might occur in parallel, as does the debugger…
You could theoretically achieve the same outcome without a custom event (using the “Only when” conditional to test the output from the “Do a search for” action), but I personally don’t like how messy it can be to read and the risk of potentially missing it if you add a new workflow action to the main workflow in future.
