"Result of step" behaviour

Hi all!

In an API workflow I do not have the luxury of Custom states, so instead I thought of using the ‘Result of step…’ in its place, when all the actions change the same field in the same table ( Field=score).

What do I want to Achieve? I want to understand what happens when in a workflow I want to compare a value against ‘result of step…’, but that step has not been executed (condition not met), yet a step before the not executed step has filled out the score you want to compare with.

The API workflow determines an endscore for a week for a user.
Step1: “If you have achieved A, you get score x” (Thing to change ‘score’ in table 'TT)
Step2: “If you have achieved B, you get score y IF score y is higher then Step1 score”
Step3: “If you have achieved C, you get score z IF score z is higher then Step2 score”

if step 1 changes field ‘score’ in x and step2 would change field ‘score’ in y but the condition is not met (thus step2 is not executed), when in step3 the condition is ’ score z> ‘Result of step2 score’, will the condition of step 3 then check score z against the last value of ‘score’ from the table ( thus the value x) or will it just automatically say condition is met because z is > then something that does not exist ( Result of step 2, which has not been executed)?

Side remark/question: When using 'result of step x in an API flow, does the server use values from internal memory or does it wait till Step x has been written into the database, and then reads out the value from the database?

It’s supposed to be this one so it’s using the database value. If you read the value from the action, you got the new value. @Bubble ?


I’m not sure about this one. But, I’ve noticed the system takes old values. So, I’m using do search for …: first item for checking the new value, just in case.

1 Like

Hi Lottemind.md,

This is especially what I am not using when I change a value in a database AND want to use it in a a short period of time, it becomes really tricky:
Sometimes Bubble will return the old value which was already there ( the new value is still not processed), sometimes it is the new value. This is why I use Custom states so much. However those are not available in an API workflow, hence I hope the ‘Result of step …’ really gives the last value of that field :slight_smile:

Super curious, I am building with your suggestion in mind, It is just something I can’t exactly pin down: what actually happens with a ‘Result of’ in an API workflow? Custom state -> presume it is internal memory ( thus always last value there, but flushes with reload), change a thing-> Writing on disk ( thus timing determines which value you get when reading it out), but this one?
I would love to know how it works!

We don’t have all the details of the operation, but technically it will check the condition, write the value (s) to the database, and then execute the next action. I’d say it’s a bug if you end up with the old DB value.

I can now confirm it ends up ‘empty’ if ‘step 2’ is not executed when referrering to value x from ‘result of step 2’ it will come out empty, and does not return value x of step 1…which is really annoying. The whole point of ‘results of’ is so you can make sure the sequence is followed.
And because it is an API I cannot go for a Custom state…
Any tips?

1 Like

with api workflows and the difference between using result of step x or do a search for.

I found that result of step x doesn’t work if you are running an api workflow on multiple items. For example I create a list of things from a list of numbers. So my api workflow first step is to create a thing, and it runs the api workflow based on the list of numbers. So, if I have 15 numbers in my list of numbers, the api workflow creates 15 separate things in my database. That part works fine.

The problem is that I also want to create a list of those newly created things. This would be step two in api workflow and my first attempts were to use “result of step x”…that didn’t work as I wasn’t getting all newly created things added to the list. So I might have only 9 out of 15 items added to the list. My thought is because the api workflow for some reason may actually finished creating thing number 3 before it finishes creating things number 2, and so that second thing created doesn’t get added to the list.

My next attempt was to use the do a search for in step 2. That also didn’t work. I had a long set of emails with support over the issue. Their latest suggestion I haven’t taken the time to put together yet to test if it solves the issue, but they suggested recurring workflows for adding the newly created things to the list.

The problem with the do a search for as step 2 in the api workflow is that the app times out since it is at one point doing up to 3 or 4 searches simultaneously as it is part of the api workflow. What ended up being the result is that I would very rarely have all items added to the list, most of the time the list would change count, going from 15 items down to 6 back up to 9 and finishing on only 4 items in the list.

To say the least it is a very disturbing idea that there was not an explanation for why the behavior was the way it was on do a search…my imagination told me that it was a serious bug as I would assume even if I had issues with the app timing out because of multiple simultaneous searches, the last search performed should return all the newly created things from step 1; unfortunately that doesn’t seem to be the case and instead the final searches were probably cut short because of the app timing out and not finalizing the search before it failed.

I personally believe there should be a better and more straightforward way when using api workflows to get the results from step 1 to be added to a list created in the second step. I’m going to follow bubble support advice on the suggested workaround with recurring workflows and hope I get the results needed, which is a list of things that contains all the relevant things.

If you feel your situation needs more attention, reach out to bubble support. They do take the time to investigate issues and always respond in a timely manner, although it may take you a considerable amount of time to explain all the details of the problem and how the app functions and is set up before they are able to determine an issue. Usually stripping the app down to a single page with a single step to isolate the issue is whats required.

1 Like

Tnx for taking the time to share, 'do a search’in a sequence of actions has proven quite unreliable at times…even custom state, for that matter, when tha system jumps into some sort of non-sequential execution of workloads.
My new attempt is for every ‘make change to a thing’ action to use ‘result off’ as indication of the thing to change , to force sequencing of the actions, and then in the actual action use ‘do a search’. Hopefully marrying the sequencing and a definitive result every time. First results look ok.

The struggle is real ;), Enjoy your Christmas!

Well that was not it. If you use a make a change on ‘result of step x’ but x has not been executed, then even though all conditions are met the action will not be executed. However, if you just use ‘make a change on’ with ‘search a thing’ you cannot dictate a specific sequence of actions when the sequence itself is absolutely essential.

Solution that seems to work now:

@JohnMark, @lottemint.md @boston85719 @sudsy Thanks for thinking with me

1 Like

thanks for posting this…made me think of a possible way to solve my issue by putting a condition on step 2 “do a search for” to add the items to the list…I think for me do a search for would need a condition of when result of step 1 sort number is 15…that could help me to only do one search executed after the last thing from the list of numbers is created.

1 Like

I was given the advice from bubble support to use recursive workflows to help resolve the issues I was having and it worked.

It also enabled me to use the “result of step x” in those api workflows.

The recursive workflows basically cause you to schedule an api workflow ( NOT on a List ) and then you schedule the api workflow in the workflow itself ( notice my step 4 is calling the same api workflow it is in )…

Set a conditional on how many times the api workflow should schedule itself.

Now my list of images gets populated correctly, never does the app time out due to capacity ( because recursive workflows cause each one to initiate individually so the capacity used is only for a single event, not all events at the same time the way api workflows on a list do )…

@SenorPelota this may be something to explore more to see how it could help you get the use the result of step x in your workflows


Fun! Exactly how I resolved it. The solution I mention above is in an API workflow that is being called for in an API workflow on a list.

Good stuff.

1 Like