Hello. I’m having difficulty with some Custom Events.
I have several workflows that have many steps and need to be triggered from multiple sources. This is a prime example of when to use a Custom Event.
However, many times I cannot use the Custom Event because the workflow needs to set a state, or some other action, which requires a certain scope such as a particular cell of a repeating group.
I know about the Orchestra plugin and am using it, but my question is specifically about Custom Events. (I cannot get Orchestra to work in some cases because I have nested repeating groups or other factors.)
Is there any way to give a Custom Event the same scope as the workflow that called it? So many issues could be solved if there is a way to do this. In other words, every time a Custom Event is triggered, it has access to all of the same elements as the workflow that called it.
I suspect this is not possible, but I wanted to ask. I have about 20 steps that have to be repeated in at least 15 workflows if I can’t just call a custom event.
Thank you for the suggestions. The backend workflow is a non starter since I cannot set states from the backend and I do a lot of that.
I’ll explore the reusable idea though. Thank you. I think that might get me there! I have to check how often I also need the workflow from outside the RG, but I suppose I can place the reusable there too.
Actually, after thinking about this for a minute, I have the same problem. The workflows in a reusable are not exposed outside of the reusable.
If you meant to also put all of my elements in the reusable, I just spent the last month and a half pulling everything OUT of a reusable that had been placed in my repeating group. It was causing all kinds of problems that I won’t get into here, but it was necessary for my app to not use the reusable in this way.
Also, the workflows in the reusable don’t see the elements outside of it.
Also, I do need to trigger workflow from buttons on the main page too, as well as other triggers. So I don’t think the reusable idea will work after all.
Another idea. If I have a workflow that is triggered by a button click, is there any way to simulate the button click from a different workflow?
In other words, to have the first workflow act as a sort-of custom event so I only need to build (and more importantly, maintain) the sequence from one place. And I trigger the workflow by telling Bubble that the user “clicked” the button.
I’m telling you that a backend workflow is the best option here… you can add parameters for all of the states you use and pass the states into the API workflow parameters.
It’s almost never logically required to set states during a workflow.
I understand why you suggest the backend API workflows, but I’m sure they will not work here.
First, the states are necessary in my workflows. A button click could trigger the creation of a new database Thing, which is then displayed in a repeating group, but is styled based on the status of other elements on the page. That’s partly what the states are used for.
Additionally, most of what the states, and these workflows are for, is directly related to the UI/UX. Backend workflows can be slow and the UI would seem unresponsive to the user. Results must be instant.
And last, with the new WU, I am doing my best to minimize the cost. For example, if I have a popup where the user has about 15 fields that can be changed, I am storing the element’s values in states until they click Submit so that I only access the database once to make all changes together. Why states instead of simply the element’s value? It’s necessary because of scope. It allows me to access the current values from both inside and outside of the RG cell. (The states are generally on the RG itself, so there isn’t a need to identify which cell and then find the value.)
Anyhow, I will still consider it as an option, but my experience is that backend API workflows can be slow to execute and are not appropriate for UI tasks.
You don’t need states for that. That’s conditional formatting. If you need information about other stuff on the page to do the workflow, send it as parameters to your backend workflow. It’s logically equivalent to using states inside the workflow.
It’ll be a tiny bit slower. You can add a loading icon while it happens. Here’s me running a backend workflow (8 actions) when the user signs up, and only navigating the user to another page once the backend workflow has completed. This is clean and simple. Users don’t mind waiting so long as you tell them something’s happening.
How’s that relevant? You reference the states in your custom workflow. Fine, makes sense. You say you cannot reference these states in a backend workflow. That’s wrong. You can if you pass the states as parameters to the backend workflow. Then, it will be functionally identical to your current custom workflow.
Would you use a task manager app that waits for a backend workflow to update the UI after every click? It needs to be totally snappy. This is not a popup form. For your example sign up form, a backend workflow is totally fine. This is all about the UI and a satisfying and responsive UX.
I’ve personally abandoned task manager apps because the UI was clunky and slow to respond. I don’t want my users to loose a train of thought because they are waiting for the UI to update before taking their next action. Even a second or two is too much of a lag.
I’m also trying to put as much of the app as possible on the frontend to minimize WUs. Most of these workflow steps do not require database access since I already have the data in memory, so adding backend workflow would just not be feasible from a WU perspective.
Anyhow, thanks for the input. I always appreciate help from others and perspectives I may not have considered myself.
You’ll get half a second of delay from calling the backend workflow. The speed of the actions in the backend workflow will be the same (if not slightly faster) speed as in the frontend.
What you gain in WU efficiency you may lose in client side performance
I’m releasing my app in a week or two (10 months in the making). It’s far too late to consider such a major shift from using states to using parameters right now. I was just looking for a way to use custom events without losing scope of the original workflow.
After release I’ll test out your ideas of using backend workflows instead. At that time I could take some time to restructure if necessary.
The add parameter button will let you set parameters for the custom event
Give it a name of whatever you want and set the type of data it is, which can be an option set, a custom data type or any generic data like date, address etc.
They can also be set to optional so as not to be required every time you trigger it.
So, whatever scopes your workflow uses that calls the custom event, put them as parameters of the custom event, and when that workflow calls the custom event, use the values/scope from the workflow actions as the parameters values using the ‘result of previous step’ to access the values from the workflows series of actions that you need.
You don’t need to shift from states to parameters. You can still use states. You just send the states to the custom event or backend workflow.
So, you’d go from, for example:
Button inside RG is clicked → Create a new thing with fields X = state 1, Y = state 2, Z = state 3
to:
Button inside RG is clicked: Trigger custom event with parameters state1, state2, and state3 → within custom event, create a new thing with fields X = state 1, Y = state 2, Z = state 3.
Thank you. I’m aware of sending parameters to the custom event. But that does not help when the steps of the custom event need access to elements that I cannot see in order to use those values.
My question relates to the elements that a custom event has access to, not just about the data which can be passed in numerous ways. My issue is that let’s say I have some elements on a row of a repeating group. I need to trigger the same workflows from both within the repeating group and outside of it. Sometimes from as many as five different possibilities. Without the scope to access the elements from the custom event, I find myself needing to make copies of the steps in each location or finding alternate ways to trigger them. That’s what I’m trying to avoid.
The Orchestra plugin would completely solve my issue if only it would work on nested repeating groups.
If you’re accessing the states just to view their value, without changing them, you can use the method outlined by @georgecollier.
But I feel like the problem here is that you actually want to set the states from the custom event right? As you have realised, this is more problematic, but Orchestra generally solves this problem.
Why are you saying that Orchestra cannot handle nested repeating groups?
I don’t remember it being limited in this way, I’m pretty sure you can get it to work in nested repeating groups.
If you read the forum post for Orchestra, there are many who ask about nested repeating groups and the dev responds that it was not designed to work on nested RGs.
I have found that in some cases it will work, but in other cases it does not. This is the problem I’ve it.
I think I found a solution to my problem though! I’m placing my workflow that needs repeating in one that is triggered by a button. Everywhere else in the app where I need the same workflow, I am triggering a button click with Javascript using the Toolbox plugin and the Run Javascript action.
Using the element ID, I added this code:
document.getElementById('elementID').click();
This seems to do the trick! I still need to test it on all browsers, but I know it at least works in Chrome on Mac.
Now I need to figure out how to make sure previous steps are completed before this step is triggered. I wish Bubble would give us a checkbox to make sure steps are executed and completed in order (because sometimes it’s necessary).
Thats a really cool solution. Keep us posted on whether it ends up working in all scenarios.
Guess what Custom Events can help here too. Bubble guarantees that all previous workflow steps are completed before triggering a custom event, and all steps in the custom event will finish before the rest of the workflow continues. This is a useful way of avoiding race conditions and asynchronous step completion.
EG. If you want to make sure that step 3 is finished before step 4, but cannot reference ‘result of step 3’ on step 4 (This would force bubble to wait), you could put step 4 in a custom event and trigger it after step 3.
Regarding Orchestra in nested groups:
I looked at an app i made using nested orchestra to refresh my memory. If you give a unique name to all musicians, and trigger them by name, the plugin has no problems. Problems obviously arise when trying to trigger them using ‘position in list’. So if you only need to trigger one (or a predetermined few) musicians at a time, Orchestra is still an option
Ah, but the catch is once again the custom events don’t have the scope I need. In other scenarios, the workflow I need to trigger will call another custom event which will trigger a series of 16 custom events (a chain of filter actions). If the original item that uses the Javascript is placed in a custom event, the only thing that needs to complete before moving on is that single Javascript, not all of the chain of workflows that the Javascript will trigger. Great idea though, but I’ve tried it and it doesn’t work here.
My solution so far was to add a 200 millisecond pause to allow the necessary steps to complete before moving on. It works for now, but I’ll continue to look for something better.
Sounds like you’re already using the Toolbox plugin? If you are you can use it’sJavaScripttoBubble elements and then send them values and trigger workflows regardless of how nested something is. The element “suffixes” can are dynamic.
Custom Events can help here too. Bubble guarantees that all previous workflow steps are completed before triggering a custom event, and all steps in the custom event will finish before the rest of the workflow continues. This is a useful way of avoiding race conditions and asynchronous step completion.