# Workflows, sequencing tasks and paralellism

HI everybody,

I’m finding the way workflows work a bit confusing. A workflow is invoked and I’d like it to behave somewhat like what is shown in the pic below:

Step 1:
create a thing (say a T-shirt)

Step 2:
Change a Thing
Thing to change: Result of Step 1
only when size = “Small”
field to change: price = \$10.00

Step 3:
Change a Thing
Thing to change: Result of Step 1
only when size = “Medium”
field to change: price = \$10.50

Step 4:
Change a Thing
Thing to change: Result of Step 1
only when size = “Large”
field to change: price = \$11.00

Step 5:
Change a Thing
This step needs to be executed irrespective of which of the steps 2, 3 or 4 were executed.
Thing to change: ???
t_shirt_price = This T-Shirt’s price * 1.13

Question: What do I put in the box “Thing to change” in Step 5?
It can’t be “Result of Step 2”, or 3 or or 4 because they may not execute and the result is probably unpredictable. It can’t be the result of Step 1 because if I understand this properly, all the Steps that wait for the same result are run in parallel, and my step 5 may be rrun before 2, 3 or 4
(and needless to say, I need the price to be set before running Step 5).

Any help will be appreciated!

Result of step 1 should work (try it!), but you could also do price × 1.13 in steps 2, 3, and 4 so that it’s changed directly in those steps. Only one if those will run based on the size condition, right? So the price change can happen fully in those steps.

Thanks Gaby, but if I link it to Step 1, won’t it run in parallel to Steps 2, 3 and 4?

Alternatively, what would be wrong with having each step’s thing to change be the result of the previous?

If actions rely on the result of something previous, I’m fairly certain they wait to run until the result is ready, otherwise that feature would be creating way more problems for people!

See this:

Nothing wrong with changing a thing from the result of previous, but you’d save yourself potentially three additional actions that would need conditions by including the price change in the original 3 actions that are already modifying that same field and are already running under conditions. Unless I’m missing something about the sequence, I don’t see a reason why you’d want to split it up further.

It’s like making a change to a user’s full name field to add a first name in one action and then making another change to the same user’s full name field to append the last name when you could have just done first and last in a single action.

I’m sorry. In my zeal to simplify the question I led you into a rat hole. The changes I put in the fields inside the steps were for example only and are truly irrelevant.
I just tried to make it look more real but “forumers” usually think deeper that the problem at hand. My apologies.

I had read Stavvit’s post and every other post on the topic. I (think I) understand how using “results of step x” works. What I don’t understand is, if the steps indeed all run in parallel, and I want to have a step wait for 3 others like in the graph, is there a way to do it.

As a matter of fact, I run the workflow having Step 2 run on the results of Step 1, Step 3 on Step 2 and so on, and it seems to work fine.

Sometimes, however, even if I use the result of one step in another, the second seems to be executed before the first one commits to the db.

In this case, since you know “size” before step 1, and will also know the price, so you wouldn’t do the workflows like that. There is nothing in Step 1 that you need to do the calculations so you can do it before.

That is distinct from something like “create thing A” and then add the result of that to a list on “thing b”. In which case you need the id from Step 1 (or rather Bubble does).

Where you are doing a calculation in step 1, that you then want to use later in the workflow, I have experienced timing issues (using a value in step 1 that I then want to update in a later step). I got round this by setting a Custom State to the value in Step 1 in a subsequent step, and then using that in the update. That seemed to be much quicker as was not reliant on a database save.

So I think there are usually ways round the issue timing of parallel workflows. The situation you describe may well not work in the way you describe, but Bubble allows you to do the same thing in different ways, so you can work round it.

Hi Nigel,
can you pls elaborate on this part a bit? How exactly do you do that and how do you use it thereafter? If Step 1 is creating a thing, can it also be creating a custom state?

Many thanks for the replies.

Sorry,
ignore my last sentence/question – I posted before erasing it.

This topic was automatically closed after 70 days. New replies are no longer allowed.