OK, so presumably you understand the answer to your original question now. (Which was essentially, “How do I do conditional logic in Bubble?” The answer is, “By executing a workflow step ‘Only when…’ a condition is true.”) [BTW, @kirk, you’re correct in your reply above and if what you’re saying is not yet clear to the OP, I think it will be shortly!]
So, @SenorPelota, in the case you describe here, if I understand you correctly, you want to do the following:
You have a button that, when clicked, does this:
[Compute (or get) weekly score] → [Map that score to one of 3 ‘endscores’ (which are like ‘grades’)] → [Save that value somewhere in the database]
Correct? Those are the tasks you need to complete, in order.
Each of these three things you want to do may be composed of several subtasks. These subtasks will composed of individual steps in the button’s “WHEN button is clicked…” workflow.
Don’t get too hung up how “long” the workflow gets visually. This is just kind of a byproduct of drag-and-drop authoring systems like Bubble. So, just looking at these three “tasks” in order:
- [Compute (or get) weekly score]: presumably this is some sort of running total you’re keeping. I can’t guess how it’s computed, but it could be pretty complex. It could also be very easy – maybe it’s just “Current User’s Weekly Score” retrieved from the database, right? At any rate, however we get it, we need that value locally so we can map it to a grade.
If it already lives in the database, we already have access to it. Sounds like that is the case. However, if that was not the case, the first steps in our workflow would do whatever magic we need to do to compute the value. And the end of this “task” (set of workflow steps 1 through whatever) would be to either save that value to the database (if we care about it in future) or TEMPORARILY SAVE IT LOCALLY (which we can do with Custom States which are really just Bubble’s version of local variables).
Moving on:
- [Map the score to a grade]: This is what was conceptually hanging you up. In Bubble, this part of the workflow will – of necessity – be composed of AT LEAST 2 steps. No, there is no single workflow step that is like a branch, if - else structure or case statement structure. That would be handy in some cases and might make some folks feel more comfortable. However, it’s not necessary for the most part.
As @kirk and @nikolai and I (just now) pointed out, there are several inefficient things you are doing:
-
first, you’re writing the grade value to the database 3 times the way currently do it. This WILL BE slow and it’s unnecessary.
-
second, you’re thinking about your grading algorithm a bit backward. At least the way you’ve described it, you can safely assume that all grades will be “12” unless the criteria for grades “15” or “21” are met. (So, you never actually have to map a weekly score to “12” – it’s the “default”, right?)
But how does one do these two things in Bubble?
Here’s how:
- We’re gonna need some local storage to hold our “grade” locally until we (as the second-to-last task) write it to the database. In Bubble we do this with Custom States. Custom States are just local variables that are associated with an element on the page.
In your case, you might as well just put this “grade” variable on the button itself. While you can do this in the workflow builder, here’s how you’d do it in design mode (which makes it more obvious what we’re doing… and also lets us set a default value, which will be very handy and performant):
When we click “Add a new custom state” we are presented with a dialog (just like adding a field to a thing in the database) that lets us give it a name and assign a data type to it. Yours would be like this:
That’s gonna result in the following:
See how we can give this Custom State a default? I did that, set to 12, our lowest grade.
- Now your workflow components for mapping the other two grades are going to look like this. This step is created by selecting Element Actions > Set state:
Obviously, your workflow may have some preceding steps, but you get the idea. Set the variable Grade (which is stored on this Button) to 21 if (when) the criteria for this grade is true (“yes” in Bubble terms).
The second evaluation step is the one for grade “15” – set Grade to that value if the criteria for that Grade is met. NOW, it is not clear to me if the criteria for Grades “21” and “15” are mutually exclusive. Only you might know this.
If they are NOT mutually exclusive, we need a dual condition here. I’ve assumed that a weekly score that qualifies for grade “21” would ALSO qualify for a grade of “15”. (I think this is why you ordered your workflow steps the way you did, right?)
So, we will set the grade to “15” only when “It is NOT already 21” AND your other conditions for getting a score of “15”. Like this:
Now you will note that you DO NOT even need to bother with figuring out if the weekly score was enough for a grade of 12… This Button’s Grade will already be 12 (by default that we set in the Custom State) if it has not been changed by these two preceding workflow steps.
Neat, right?
What we’ve constructed here is the Bubble version of IF… ELSE IF… for all intents and purposes. More literally, in JS-like psuedocode, it’s like we did this:
var grade = 12;
if (cond1 is true) {set grade to 21};
if (cond 1 did not pass AND cond 2) {set grade to 15};
Get what I’m saying?
Moving on:
- [Save the Grade somewhere in the database]: This part is easy, right? We’re just going to “Make changes to a thing…”. I have no idea what the weekly score is attached to in your database, but that step is going to look like:
Hope that helps!
-K-