Is this a good or bad idea to have blank change step to control workflow?

Hey all,

I want to know if I should put my sunglasses on, so I made an app for it. It’s one page:

image

When I click the “Find out!” button, it runs this workflow:

Steps 1 and 2 set a yes/no field based on the current time of day.

image

image

Step 3 is where things get weird.

image

Here, I put in a blank “change” step that references both step 1 and step 2. Why? So that I have an anchor step that I can reference further down the workflow. This should, in theory (and seemingly in practice) force bubble to run step 3 no matter what.

On step 4, I reference step 3:

image

Step 5 shows an element on the screen.

image

The concept here is:

  • I only want to run step 4 after steps 1 and 2 have resolved.
  • In step 4, I want to use the result of either steps 1 or 2. Step 1 or step 2 could be empty, but one of them won’t be.
  • I don’t want to have to branch into custom workflows.

I don’t know if step 3 is making an empty database call. If it does, then this solution adds WU cost.

It works in my little test.

Does anyone know definitively (not speculative) if this is a good way to control workflow steps in Bubble?

Bonus points if you get the Corey Hart reference.

I feel like I might be missing a very simple and obvious way to accomplish the same thing.

@georgecollier @petter @mikeloc @jared.gibb

1 Like

Implementing a blank change step for workflow control can offer flexibility and customization but may add complexity and confusion. Careful consideration and proper documentation are necessary to mitigate potential issues.

I wouldn’t say it’s good practice but it’s not make or break by any means. However there is better solutions.

There’s free APIs you can hit to return where you wouldn’t need to save to db at all.

1 Like

Hi @chris.williamson1996 , I don’t actually want to make an app to tell me if I need sunglasses. I can just look out a window. I’m asking if there’s a better way to effectively chain promises in Bubble’s workflow than having to call custom workflows or to do the hack I described.

1 Like

Backend, custom workflow, database triggers, are the most common way to guarantee promises in bubble.

You could also consider having multiple workflow events with conditions at the event level so you don’t need to rely so heavily on “promises” within a particular workflow.

2 Likes

If I have logic that either creates (X) or modifies (Y) a thing and I want to reference either X or Y without duplicating actions, I now use custom events which return the relevant Thing as a parameter that can be referenced throughout the workflow.

On a side note, where did ‘create thing if it doesn’t exist’ go? That was such a nice feature. I swear it existed.

3 Likes

That feature was deprecated a long time ago.

So many use cases for it :frowning:

Love it!

image

image

That strikes a great balance between maintainability and workflow control. And no hacks required.

I trust Bubble had a good reason to deprecate, but what a pain that there’s no way to upsert in one step. Yet you can still upsert users.

Yeah the amount of custom events and queues I have created as a workaround since they deprecated this. If they brought this back and added a do & terminate workflow, I’d be able to remove like 20% of my workflow actions…

Ok so since the update that allows custom events to return stuff, I think I’ve noticed a behavior but assumed I was hallucinating, as it doesn’t make any sense that Bubble would change the behavior. But this comment is making me rethink that.

  • API workflow has parameter thing.
  • Action #1 is a custom event that modifies thing.
  • Action #2 is a make a change to a thing for thing.

I would think that the thing being changed in Action #2 is the modified thing with the updates made in Action #1’s custom event. But I seem to be hallucinating that the thing in Step #2 is not always the modified thing but sometimes the original un-updated thing being sent in the API workflow’s parameter!
So I’ve been updating the custom event from Action #1 to return the updated thing and then referencing that thing in Action #2 instead of the API workflow’s thing (which shouldn’t be necessary), but @georgecollier is that why you’re using the CE to return the thing? Shouldn’t the modified thing in the custom event be the same as the workflow’s thing?

I mean more so the custom event is essentially an expression variable that I can change once down the line.

I’d have thought that changing a thing in custom event would mean a subsequent step in the parent workflow would use the updated thing as they run in sequence.