Forum Documentation Showcase Pricing Learn more

Can I copy a workflow to another type of event?


#1

I have an Add button. In its “clicked” event, there are several steps to the workflow. I want to duplicate all the steps of this workflow in the “value is changed” event of a different element.

Since this event is not a “clicked” event, it doesn’t appear possible to copy the entire workflow of the “clicked” event and paste it into this workflow. I’ve been able to get the job done by copying each step of the workflow which is a tedious process and prone to error as I click back and forth between events to copy and paste each step.

is there a way to copy all of the workflow from one event to a different type of event?


#2

Kind of nearly but not quite … you can copy the workflow and assign it to a different button, then replace the button with another element, but it only allows to replace with another visual element, not an input.

If you find you need the steps reused, consider putting them in a custom event, to be called from different workflows.


#3

Thanks. I will be developing the habit of using custom events. I’ve dabbled, but it isn’t a habit and I’m working with some pages from my earliest days using Bubble.


#4

Custom events aren’t perfect either, for example the parameters are extremely limited, and the workflow steps lose the context of the workflow event, but yes its useful in some cases.


#5

Not answering your question, but meta-commentary on this:

Reusability is a huge improvement area for Bubble. Way back in the Stone Age I worked on a product called mTropolis that was basically the same thing as Bubble but for CD-ROM multimedia. You could cut/copy/paste stuff like this to your heart’s content. It would just work. But it had a very clear concept of organization and abstraction layers. (And a different concept for what “workflows” represent.)

Bubble is currently way too reliant on literal relationships (“I’m on element #40008 and pointing to element #320005.”) Instead of… parent-child (relative) relationships. (“The thing I’m pointing to is my parent’s parent’s Thing.”) And this causes great consternation when copying workflows, elements and many other things.

I think the thing it’s missing is “behaviors”. (Basic encapsulation that isolates a visual element from its software function.)

A workflow is not actually about Button X being clicked. A workflow should be free floating… it is a set of actions that happen when some trigger/threshold(s) is fired. It should be possible to cut/copy and then paste a workflow onto some completely disparate/different element and change just one thing — the trigger(s) — to make it work again.

Reusable elements in Bubble are nigh impossible to create right now — at least in the sense we all desire them to. Currently they are fine for creating a running header or footer. But that’s not what we want. What we want is encapsulated components that we can safely drop on a page and — just by clarifying where their initial stats are to come from — have a consistent experience.

The way things work right now is crazy-making. It’s not actually possible to create even the most simple reusable widget (like a custom checkbox thing). Try it. You’ll spend a day trying to build a thing you can drop on any page that only needs ONE value changed (the source Boolean in this example case). Can’t be done.

It’s not entirely clear what good copy paste is except at the “view” level right now. (That is, you can copy a button and paste a lookalike button. Hooray, I guess? But copy and paste a workflow right now and all you’re really doing is saving yourself the trouble of remembering how many individual steps are in the workflow… Even if you’re dropping that copy on THE SAME DAMN THING it was copied from in a cloned page.

Tl;dr: just get used to having two windows and a screencap/snipping tool open. Get real fast at rebuilding workflows cuz it’s something you need to do a lot because reusability factor is very near zero at the moment.

I’m sure Bubble has come a long way in that department, so this is not a diss, but it’s lacking just now.

There’s obviously a different set of issues with web apps versus native code, but “workflows” as a thing are in need of a rethink (or more specifically, just a TRIGGER between the element and the flow would go a LONG WAY.)

File under: Ideas. This is all well-trodden ground, but I feel like the Bubble team is not fully aware of the prior art. (This is partly forgivable as much of the prior art is not readily available on the interweb.)


#6

Thanks, Keith.

As an ancient programmer, I saw reusability develop from paragraph (COBOL) to procedure and module and function. I practiced “structured programming”, inventing it for myself before it was a published “thing.” I went from structured to object-oriented. Systems architecture went from mainframe, time-sharing, dumb terminals to “smart” terminals, stand-along client software to client-server to SaaS and cloud and a mess of arcane names and acronyms that didn’t offer a clue of what was really happening.

In some ways things have gotten better and I am finally back to building software tools for my own use because Bubble has made it kind of possible.

But I am amazed that something as basic as a function isn’t available. And as you describe, the inability to create reusable elements is mind boggling.

Oh, and how about SQL? I suppose it’s just too hard to implement in the AWS world. But I don’t know.

Thanks, again, for your commentary.


#7

Anything that increases efficiency is always welcome, so yes functions, encapsulation, inheritance etc would be great additions to Bubble but it strikes me that trying to replicate too many traditional programming concepts early on is probably one of the reasons why previous attempts at codeless programming failed or at least never worked as well as Bubble does. I would like to think that having got the basics right, the Bubble team will continue to improve and optimise over time. Great discussion though and I hope it spurs the Bubble team on.


#8

Yeah… I’ve had this same observation. Best practice would SEEM to dictate that you should NEVER have a workflow that is ANYTHING but single step that kicks off a Custom Workflow.

All work should actually be done in Custom Workflows. But Bubble makes it too darn easy to do… “Oh, yeah, when this button is clicked, just create THIS thing and show THAT group.” It ENCOURAGES you to do this, even though it’s often (probably never in the grand scheme of things) not the right thing to do.

This is like the fourth time tonight I’ve made the same observation: Workflows are the highest level of organization in Bubble right now. And they suck… cuz they are “stuck” on the trigger condition.

SOOO many times now I’ve built elaborate workflows on some condition (like a click) and been “Oh FML… this should be a custom state so 10 different things could trigger it!”

But you can’t copy and paste a workflow. The part you want to copy and paste are the STEPS in the workflow. All two dozen of them. But ya can’t do that, because there’s no name for the steps in a workflow. A workflow is the trigger (or whatever that mothereffing block is called at the top level of a workflow … does it even have a name!?) AND the underlying “steps” and these are inseparable.

Who designed that? The Marquis de Sade?

(I jest slightly — it obviously was not designed but kind of evolved or something. Any rational designer would have added an encapsulation/abstraction layer here.

Clearly the trigger has NOTHING to do with a series of workflow steps. It’s just a condition. Clearly the STEPS are the top-level thing. What causes the steps to be executed is a PROPERTY of the steps. But the Bubble workflow page has this EXACTLY backward (it presents STEPS as a result of a condition). Every time I see the workflow page I just want to scream. “THE CONDITIONS ARE NOT THE THING!”

SURE: HAVE a condition-first view. It’s handy at times. But in general “things you need to do” are far fewer than “the conditions that trigger those things.”

Page level security is the prime example. For most pages, you need to bounce assorted non-logged-in users, everybody who isn’t the creator of the page data being displayed, etc etc. “Redirect to a more appropriate page” is the BEHAVIOR. The various and sundry descriptions of unacceptable users are the conditions that TRIGGER the behavior.

Makes zero sense that the central organizing principal of the Workflows page is conditions — as it is behaviors that are unique, but the conditions that should trigger a behavior may be many. It’s brain damaging.

Still, Bubble beats traditional development platforms, so there’s that.


#9

For the foreseeable future, I can at least build a mostly-functional prototype of the system I have envisioned and share it with others for feedback. If it has potential in the market, I may have to pay to have it rewritten. But that’s a long way down the road.

Thanks for your thoughts, Keith.


#10

‘Course, I’m being a bit fanciful with my desires here as there are lots of little issues one might run into with kicking off Custom Events/Workflows. Not the least of which is that such flows are going to be asynchronous and that may not be desirable in all cases.

Anyway, the struggle is real with respect to moving/duplicating workflows and a little abstraction here would be a great quality of life type improvement for Bubble.


#11

Ouch, @keith.

Did you say “asynchronous”? What a nasty, murky business that is. Is this true of all custom events?

I am trying to assemble custom workflows that will invoke other custom workflows to update records and properly update references between updated records and some related records.

Here’s the outline of a scenario for a “time management” system, presented in its simplest form.

Two types: Project and Action.

Project may be what we classically think of as a project or it could be any name under which commitments to do things are gathered, e.g. a volunteer committee.
Action is pretty much what the name implies. It’s something you do to complete a Project.

An Action belongs to a single Project. Therefore, Action has a Project field of type Project. It connects the Action to its Project.

A Project has multiple Actions. Therefore, Project has a list of Actions containing every Action belonging to a Project. It’s critical that this list always be accurate.

The Project associated with an Action can be changed. Think of this as assigning an Action to a different Project. When it is changed, it must be removed from the Actions list of the original Project and added to the Actions list of the newly assigned Project.

Because Actions can be updated in any of several pages of the system, I want all of these updates encapsulated in reusable element(s) with custom events. I currently have too many update workflows replicated throughout the system and I need to bring them all together into appropriate reusable element(s).

I’m thinking of having workflows for creating new and updating existing Actions separate from workflows for reassigning an Action to a different Project.

Am I setting myself up for trouble? Am I concerned about a non-issue?

Thanks.


#12

You’re probably concerned about a non-issue. It’ll get obvious real fast if there are any issues.

Here’s the thing: Workflows are basically like asynchronous functions in JavaScript (which isn’t surprising as Bubble apps are basically node.js apps at the end of the day). At least, the CAN be.

This is actually super-handy and performant. It can help you minimize execution blocking BS that might happen in your app. For example, I have pages where there’s a bunch of initialization that needs to happen, but it can totally be completed in the background while the page loads. So, on page load, I kick off an API workflow to go fetch a bunch of stuff, ping some external APIs, etc. Doing it in this way doesn’t block page rendering.

Kicking off a Custom Workflow is also like this. That process (in most cases) doesn’t block anything else going on on the page (like, you don’t have to wait for the status bar to update, etc.). So that’s really cool when you can get away with it.

But back to my original comment where I was musing about “it might be cool to build your app in such a way that your workflows are not ‘stuck’ on a button or whatever”:

What I was saying is that, if one DID fancy to construct their workflows such that any non-custom workflow was just a single step that kicked off a Custom Workflow, one might have to be mindful of potential issues from asynchronous execution.

Within a given workflow, the steps SEEM to be executed synchronously (one after the other) in most cases. It could be that workflow steps ACTUALLY execute ASYNCHRONOUSLY when possible. However, in actual practice, a multi-step workflow will do some thing, followed by some other thing (that depends on something that happened before), etc. essentially forcing the steps to be synchronous.

One does see cases that might indicate asynchronous execution within a workflow in certain situations. Here is an example:

Here’s a workflow I was creating recently where it is necessary to ensure that certain custom states are initialized (cleared out and set to null) before proceeding. (If the values are not reset to null first, certain interface problems occur – there’s just a lot of dependencies on the page):

Anyway, Steps 1 through 4 just null out the values in some custom states. Steps 5 and beyond put new values into those states and do some other stuff.

STEP 5 is a very short PAUSE step. What I found is that, without the PAUSE, things were happening too fast:

The custom state were not NULL for a long enough time for various interface elements that depend on those states to update themselves. The question is: Is it just that they were NULL for a very short time?.. or is it that they NEVER get set to null due to (what would usually be very smart) Bubble behavior.

Why was this? There are several possible/likely explanations:

    1. Synchronous but too fast” explanation: Steps 1-4 do not take an appreciable amount of time to complete and so the values (while they may have gotten set to NULL very very momentarily), get more-or-less immediately overwritten. If that’s the case, the steps in the workflow ARE being executed synchronously, but it’s just too dang fast for certain other elements (which do things “Only When…” these custom states update).
    1. Asynchronous” explanation: Steps 1-4 and later steps 6-8 might actually execute ASYNCHRONOUSLY, because none of those steps explicitly depend on each other. If that’s the case, those actions are being fired off not exactly simultaneously, but VERY VERY quickly and so (for example) Step 1 and Step 6 (which both make changes to the same custom state) are kind of in a race. Could be that Step 1 doesn’t even get a chance to complete.
    1. Optimizations” explanation: It is possible this behavior is NOT due to the synchronous/asynchronous behavior of workflow steps. It could be there is an optimization in Bubble that sees that Step 1 and Step 6 LOOK LIKE they are redundant. (A value gets set for “Start Date” in Step 1, but nothing in the workflow is done with that value. The same value is then set again to some different value in later Step 6.) So it could be that Bubble just is just filtering out apparent stupidity (Step 1) and ONLY executing Step 6 as it SEEMS (to the workflow). This is a completely rational optimization to make and it probably saves tons of time in poorly written workflows.

Whatever the reason, by adding Step 5 (the pause), I’ve forced the workflow to both work a lil’ slower AND forced a measure of synchronous behavior (if indeed asynchronous execution of anything is going on here). Step 4 MUST complete before we take a very short pause. Step 6 can only start AFTER the pause is finished.

So, either way, it fixes the problem.

OK, so that’s a kind of interesting example, eh?

So, it’s not 100% clear to me when and how INDIVIDUAL STEPS within a workflow might executed asynchronously (or whether they ever do at all). However, when a Custom Workflow is kicked off, that definitely creates asynchronous function activity.

(This is a good thing.)

Didn’t mean to scare you or anything. Point is: just like when doing things in node.js, you’ll sometimes run into funny issues that might arise related to synchronous/asynchronous behavior.


#13

Thank you for the very thorough answer, Keith.

Note from left field: herein lies the fallacy of “code-free app development”. Even in Bubble, you cannot develop anything at all sophisticated without understanding what is really happening under the covers.

Thankfully, 30+ years of software development have prepared me to understand a lot of this.


#14

Here’s my observation on Bubble’s workflow synchronicity …

If custom events are scheduled in a workflow step, then they run asynchronously to the current workflow.

If custom events are invoked in a workflow step, then their steps are as synchronous as normal steps.

In general, normal steps are asynchronous (but initiated in order) unless Bubble sees a connection between them, like using a previous step’s result, or using a custom state value that is set in a previous step, or using a database field in an expression where the field was set in a previous step (it was really messy before this last one was added!).

What is missing is connecting plugin elements in this checking, i.e. if a plugin is altered in one step, a future step should wait for the plugin to finish its update before using its value.

Then, in general, the workflow running on the server is asynchronous with the workflow running on the client, but there are synchronising conditions where the server will wait for the client to catch up, like for example, setting an element’s value to a database field.

@josh has posted some info about this, but it really does deserve a clear section in the Manual.


#15

This feels intuitively correct to me even though I’ve not tested all of this scientifically. And @mishav would know, if anyone would.

To the point about “synchronizing conditions” between server and client-side workflows, obviously the best practice would be (in general) to avoid doing that (causing them to happen)… I kinda think of “API Workflows” as being for situations where I can safely just “hand things off” to the server.

The one related thing that’s still a bit puzzling to me is :make static. I’ve not used that a lot, but in the times I’ve experimented with it, I don’t see it having any effect. (I think this is another thing that’s probably just weakly documented. I get the feeling it only works on the results of a :merged or something.)

The reason I think of this as related is that the only thing that seems to actually get “made static” is lists sent to API Workflows.


#16

I’ve played with make static, it seems weird, but also dependent on where in the expression its put.

Its too long ago for me to remember the results, but try different variations:

search :make static 's :first item 's name
search 's :first item :make static 's name
search 's :first item 's name :make static


#17

A-ha. That would make sense. (I’ve always tried to apply :make static in a very different context. And probably one that doesn’t make sense in Bubble terms.) :man_shrugging:


#18

“Add a pause before next workflow” isn’t what you expected. It works only on client side. Don’t expect the workflow to be slowing down (each workflow are execute at 200ms average or more). The moment you will add units, the result will change. And yes, it is missing an action “pause between workflow”, very important feature.