Awesome - Big addition - Thanks to the development team!
Thank you !
Stupid question, but once set up I gather we still have to initiate the API endpoint with an event - such as tick a box. There is no way to activate the API from the ADMIN?
Update answer to my question is NO admin, but works great when implemented using front end. The use case here was to run an API workflow to update a records in a growing database.
Am I interpreting this correctly that this allows you to override restrictions on monthly/weekly/daily schedules that have been in place for the different Bubble price levels?
I.e. run a daily update of something by re-scheduling every 24 hrs?
Good question. I’m interested in knowing this too.
Could you please help us here?
What are the limits on scheduling workflows recursively?
Could I set a 24-hour loop-like check flow which would trigger on-list flows?
It’s great to see the confidence to lift this restriction! Really nice feature.
I was wondering if there any potential downsides to running a recursive workflow idle. For example in your example, what if you remove the condition on rescheduling the workflow. Will it use any server capacity if the list to run on is empty?
Aaaawesome! Could this be used to e.g. trigger a workflow every hour? So I trigger manually the first one and that one is going to trigger itself every 1 hour. For checks, this would be awesome, guys.
I am still having a hard time implementing this into my application. Does anyone have any videos that explain how this works in simple English?
I want to make sure I’m not creating a loop that crashes my app or anything like that, or worse, something that deletes things that are not supposed to be deleted.
All I want to do is, when the user “deletes” something, that I will make a text field that says “Delete” which hides it immediately from their list.
Then on a monthly basis, because that’s all I’m allowed to do on my plan, go through and delete all the things marked “Delete”.
Can anyone do a mock set up or possibly a video explaining how to do this properly? I really want to set this up in my app to speed things up but want to do it correctly.
Thanks for any help in advance.
When you user deletes a thing, you write “DETETE” in a field.
Create an API flow to do the following (call it DELETE THINGS):
Action 1. Delete a list of things on the list: Find records which contain DELETE.
Action 2. Schedule API called DELETE, and put schedule time as Current Date + 1 day.
Then you need to go on any page and create a button and attached the following action to it:
Schedule API called DELETE, and put schedule time as Current Date.
The above will basically start a loop which will go around every day and delete things that a marked as DELETE.
You will have to trigger/schedule first round manually in both Test and Live Version.
Thank you! So basically I need to make an admin page to put a button on to start it? Is there a way to stop it with a button from an admin page too? Also, when normally is a good time to run these? People use my program from around the world. Maybe I can do a notification while it is processing somehow to let them know it might be slow at the moment?
Why do it in bulk? When user “deletes” something, update your flag and schedule an api workflow to delete the thing with a start tine of current date/time + whatever your interval is.
If you wanna be really cool, set a date field on the object that represents that expiry time. Then you could easily see how much time the thing will continue to be in the dB.
The above seems to be a good way too.
To answer your question, instead of You could create “on load page” action which would create trigger a thing and write down scheduled api flow id , then when this api flow is run and scheduled itself again change this thing to record new api flow id. This way you will have current id written down. Otherwise you can see all scheduled flows in Scheduler section in settings.
But I think you should try the above method: when a thing gets deteled by a used, mark it as deleted and schedule deleting api straight away. This way the load would be more evenly distributed.
Finally, I personally don’t see a need to delete thugs permanently, just hide it
Hmm. All good points. Does having so much in the database slow the app down eventually. Like if it has to search through so much more data then it would eventually slow down right? I just thought maybe it was good dev standard to delete a clean up your database. I’m a newbie though. What would I know. Haha.
I think maybe because I am on a personal plan and it won’t allow me to do an API except once a month or something like that. I guess I am still trying to wrap my head around all this. I think it will greatly improve my app once I figure it out though.
One big reason to push processing to a batch is when your app is under higher load at certain times of day, or certain days. Evening out the load can make for better performance and/or a cheaper plan.
best day of life really???
I’ve been out of the loop. What happened?
@josh, can you please explain something?
My loop needs to create about 10-12 things, and I use a counter which is indexed in each iteration of the loop. So each iteration it counts up, and the loop stops once the index is equal to the number of things it is supposed to create. In your example, your scheduled date for the recursive action (loop) is current date/time + 2 seconds. I set a loop up this way in my app and it seemed to work fine.
Since I want my workflow to complete as fast as possible, I set the interval to current date/time (with no delay) to see if I could get it to run faster. However, when I do that it creates 2 or 3 more things than it is supposed to. So this makes me think it is not actually waiting for the iteration to be complete before starting the next iteration of the loop. If it was truly looping then there would not need to be a delay because the next iteration wouldn’t start until the first one is complete.
Any idea why this is happening? For now I’ve just gone back to a 2-sec delay, but it is a bit disconcerting that it doesn’t really seem to solve the problem this is meant to solve.