Using Custom Events as Variables in Backend Wokrlfows

So, without question, the biggest and most useful enhancement that Bubble have released in recent months, is the long-awaited ability to return data from Custom events.

There are still lots of very basic things missing in Bubble though in my opinion, not least of which is having no native ability whatsoever to declare or use variables in Backend workflows. Which ultimately makes creating complex backend workflows even more complicated, and harder to maintain, than they need to be.

Of course, with page workflows we can set custom states - and these can be accessed from anywhere on the page), but there is no native equivalent of custom states for backend workflows.

Working with variables in Backend Workflows

One common workaround to this has been to use Make Changes to a Thing (or list of things) to define things for use later in the workflow. But, of course, these can only be used with Database objects so are no good for things like Option Sets, or primitive datatypes.

A more useful solution to this omission is to use a Plugin, such as List Popper, which basically lets you create and define variables, of any type, in backend workflows.

I’m a big fan of List Popper, and have used it extensively for exactly this purpose in complex applications and workflows but, unfortunately, with the new pricing model plugins such as these can be costly in WU, as well as rather slow, especially when using many of them inside a workflow.

But now, thanks to being able to return values from Custom Events, you can use a Custom Event in exactly the same way as a plugin like List Popper, for a fraction of the WU cost.

You just need to create a custom event for each type of variable you want to set, with an input and output of that type, with a single action to return the input value. That way it acts just like setting a variable.

(actually you could probably use just one custom event, with multiple inputs and outputs, instead of one for each type).

Then, in your backend workflow, anytime you need to define a variable, just trigger the relevant custom event and enter the value of the variable. You’ll be able to access it later in the workflow as the result of that step.

Testing This For Speed & WU

I wanted to test this out to see how much difference it actually makes over a plugin like List Popper, in both speed and WU cost. Presumably, triggering Custom Events in a backend workflow still incurs the cost of a server action (although looking at the logs, nothing was shown individually for this)… so I wasn’t too sure whether there would actually be much saving in WU.

So I set up a fairly simple workflow, in which 10 variables were declared (some texts, numbers, and database objects, both singular and lists), before outputting the final variable value to a database object.

I ran this 10 times for each version of the workflow.

Using Plugins

In the first version of the test I used a plugin (specifically List Popper)

The average time it took to run was 2.5 seconds (although the slowest run was nearly 8 seconds).

The WU cost was consistent across all runs, at 10.56 per run.

Using Custom Events As Variables

I then ran the same workflow, but this time using Custom Events as variables instead.

The average time it took to run was 0.8 seconds (the slowest was just over 1 second), with a consistent WU cost of 2.5 per run… less than a quarter of the previous method.

Comparing to a node.js script

As a comparison, I thought I’d run the same test using a single ‘Run Server Script’ action from the Toolbox plugin, to establish all the variables in a single workflow action, and output the final text.

I fully expected this to be the fastest and least WU costly method, but to my surprise it was actually slower and more costly than using Custom Events, across all 10 runs of the test.

The average time was 1.01 seconds, and the WU cost was consistent across all 10 runs, at 3.11

So, using Custom Events was clearly the best method, on both measured criteria.

In Conclusion

As things stand, there is still no specific native way to declare variables in backend workflows, but using Custom Events in the way described here does offer a solution which is much more performant and less WU costly than using plugins to achieve the same thing (at least according to my testing here).

As I mentioned above, I’ve been a big fan of List Popper over the years, and have used it extensively in many apps, but with a 75% saving on WU cost I’ll probably look to use Custom Events from here on in.

That is, of course, until Bubble release a native way to work with variables in Backend Workflows.


What’s funny is I was literally just thinking about this the other day while developing my app about how useful it would be to just have a variable I can set in the backend workflows…

Good investigative work. Perhaps one day we will have a “Set a State” in the backend.


Yeah, that’s what we need… it’s crazy to me that we can’t do that…

And it really shouldn’t cost any WU at all to declare and use variables in a backend WU (aside from any associated WU cost in retrieving data from the database).

Thanks for sharing!

P.S. Tips category color changed? at first I thought you’ve been searching for a freelancer or a gig cause new color is similar to Jobs / Freelance :grinning:

1 Like

I will no longer question my use of BE custom events anymore. Great stuff and thanks for taking the time and sharing this Adam @adamhholmes . :rocket: :rocket: :rocket:


Impressively thorough and well written. Thanks.

1 Like

Hey @adamhholmes, awesome overview. Would you be able to give an example of declaring a variable with a Custom Event?

You’re awesome mate. I love reading your posts when you do actual tests… Thanks

1 Like

How did you measure the WU’s? did you dig through the logs?


As I said, just create a custom event which returns the same value it receives:

Then, just trigger that Custom Event in your main workflow to set the variable:

Then you can refer to that variable later in your workflow:


Yeah, the logs show the total WU cost for the whole workflow.

1 Like

Legend, thanks!

Hello and thanks for the test .
I used it as variable the moment the feature was available in many different situations .

But I’ve noticed a bug :

When you use custom event to return data and use it like a daisy chain , it appear that ,in the chain, in a different moment ( custom event number 8 or 9 ) , the return data is different ( and sometimes is empty ).

I explain : every custom event I’ve used , got a return data . It’s basically a yes/no answer to determine if I launch or not different other custom event .
On my custom event number 8 or 9 ( depending on try ) , I’ve included after that a console.log to verify the return data and an other one in the custom event itself to verify the information submit in the return data.

And … oups there is a bug :
The first console.log give me a « no » as return data … and the console.log in the custom event itself got a yes from the informations provided …
My daisy chain in backend has stopped … so I wonder: is there a limit for now to use it as a long chain (did I miss something in documentation / information provided from bubble about this new feature ?) or is it clearly a bug … or, worst for me , is it a problem of privacy rule wich is « lost » during the daisy chain ( you check in the api workflow the ignore privacy rules , but the privacy rules « ignoring » is lost during the process because of many many custom event … just a guess ).

However , it is a powerfully feature as you mentionned with a great test , but I think you have to use it with caution and verify the return data very carefully .

1 Like