I have some workflows that take very long and my users are very impatient and do not always notice the progress bar at the top of the page.
Is there a way to access that bar and manipulate it, change it to something else?
My solution now is to have an alert showing when the ‘print to pdf’ button is clicked for a duration that I can still safely say the workflow is in progress, then show another alert when the file is printed successfully.
This is not elegant. My next idea is to create a group with a message that will be visible upon clicking the print button until the final alert shows. But accessing the progress / loading bar at the top of the page would be even better.
4 Likes
Not really, we don’t expose that.
Another way to address that issue (long WFs), that I’m not sure if is applicable for your particular case, but still worth to mention.
Use Scheduled Events\API WFs:
Meaning that the user that clicked a certain Button does not need to wait for the whole WF to be completed, but instead - you just schedule the even to run right now (Current date\time) in the background, while user can continue browsing their stuff.
Another way to handle this gracefully when you cannot really send the user on their way (like in your case, as far as I understand), would be to include the step Show an Object before the API(or any other long call) showing for instance, some loading icon, and then include the step Hide an Object right after the API call step.
This way, while your data will be loading for whatever reason, the end-user will be seeing the Loading Icon (we usually do them animated\rotating), and it will disappear as soon as your long step is completed.
Check it out and let me know if any of the two work for you.
Vlad.
GM at Bubblewits - Bubble Certified Partner
http://bubblestore.io – a place to buy Bubble templates for landing pages, e-commerce, workflows, APIs etc.
http://iambubble.com - one page Bubble demo
http://builtonbubble.com - Collection of apps built on Bubble
1 Like
thanks, will definitely look into this. Users need to work with whatever they will be waiting on so it doesn’t really matter that much but the second suggestion sounds like a proper solution. I’ll look into it right away.
Nevermind, I didn’t read your post carefully enough. In the second suggestion, indeed you cannot navigate away from the page.
What would make a custom event make a better choice rather than just adding the workflows directly when clicking the button?
Sorry, I am not sure I understand the question.
Can you rephrase, please?
Sorry, just wrapping my head around these custom events/scheduled api workflows so I’m only just getting it.
Another way to handle this gracefully when you cannot really send the user on their way (like in your case, as far as I understand), would be to include the step Show an Object before the API(or any other long call) showing for instance, some loading icon, and then include the step Hide an Object right after the API call step.
When I just add a regular workflow with an alert and then all the actions, the result is the same as when you schedule a custom event, am I correct? Running a scheduled event will not allow you to navigate away from the page as opposed to an API workflow.
When I add an element to show after the scheduled API workflow, the alert/element will show immediately and does not wait for the workflow to end. I guess this is expected behaviour? Not being able to add an alert or show an element on the actual API workflow page, I wonder how you show something for the time that the API workflow runs in the background.
When I just add a regular workflow with an alert and then all the actions, the result is the same as when you schedule a custom event, am I correct?
The end result - yes. The process - no.
In case you’re triggering a “normal” workflow, the user will see the loading bar and will essentially have to wait for all the wf steps to be completed until he can do anything else.
If you schedule the wf/custom event, then the actions in the event\wf will carry on running in the background, significantly reducing the loading bar" crawl time and in most of the cases - improving the UX.
On the second though now - I think you’re referring to using Trigger Custom event vs. Schedule Custom Event\WF.
In the first case (Trigger event) - yes, it probably will be pretty much similar to just using the same actions in the same WF.
When I add an element to show after the scheduled API workflow, the alert/element will show immediately and does not wait for the workflow to end. I guess this is expected behaviour?
Actually, no. I create an element, tick off for it to be invisible on the page load, then inside the same WF add the actions to show the element before the API call, then action to hide it after the API call, and it works like charm.
Would be great if you could share the editor link, as I see we’re getting down to low level of details already 
No I mean schedule a custom event. It will not allow you to move away from the page while it is loading so in that sense it is the same as the normal workflow for creating a thing.
The workflow that I have setup takes 10’s of seconds and involves creating a thing, creating a list of other things, attach those things to the first thing, print a PDF, save that PDF as a File thing and then email that to a user.
It looks like when the workflow starts, once it hits the API scheduled workflow, it fires it off and it will run in the back but then the workflow continues with the next elements in the workflow, hiding the element shown at the beginning of the workflow.
If I could show and hide the element on the actual API workflow page, then I’m pretty sure it would work because that holds all the workflows for that API Workflow.
This is on the page with the button:
This is the API workflow:
the hide action of groupZZ will not wait until the entire API workflow finishes.
I added an icon and made it’s color change to green when the API call accomplished the data change on the last item on that list. This way I knew the api workflow was completed.
