This seems like it should be simple, but I can’t seem to puzzle it out: I want to create a backend workflow that executes an API task multiple times per day–for now, maybe 90 minutes.
However, I’m confused about:
what type of backend workflow endpoint to use (recurring event or API workflow or custom), and
what action(s) & step(s) to use within the workflow (plugin API action, custom event (API workflow, recurring event, etc.).
I’m also confused about what initially kicks off the backend workflow. I’ve seen examples where the backend workflow gets triggered when a user signs up, but I need my backend workflow to run every X hours or minutes (i.e., not based on a user action).
Can someone point me in the right direction for how to configure something like this?
You want to use a regular backend (API) workflow - not a recurring event (they can only be run once per day, even on the highest paid plan)…
Just create a backend workflow, that does whatever it needs to do, and then (as the final step) schedules itself to run again 90 minutes later.
As you mention, you’ll need to kick it off initially from somewhere (such as an admin page, or even just a temporary page created for the purpose). once it’s running it will continue to run every 90 minutes (or whatever time you schedule it for) until it’s cancelled.
One thing to call out on this is that it’s cleaner to explicitly build this mechanism into your workflow rather than go hunting down scheduled calls on the server logs. So you should have a checkbox / similar on your admin page where this is triggered from that is linked to some simple, one-off object in your database. That yes/no field is then a condition on the Scheduled Workflow - it will only run if the value is still yes. This is what I have for this - the blue button launches the thing, the toggle is the Yes/No conditional and the input controls the interval between workflows:
We add “enable workflow” flags to our admin users and allow them to enable/disable each others workflows. We have also been experimenting with more sophisticated methods of using database triggers to run recursion. Which reminds me I need to post up the example I have of the Lorentz Attractor run off of recurisve database triggers. I think this method also gets around Bubble’s threat to cancel any workflows that recurse for more than 24 hours.