The idea is to be able to set up a regularly scheduled event. The way I would think to do that would be to schedule an API call that will then schedule itself for a later date (and so on). Then you just enter a condition on the workflow that will be used to interrupt it in the future (like cancelled = yes). However, it looks like it’s not currently possible to schedule an API workflow that will then schedule itself (or even a different API workflow) for a different date. I assume you guys did that to prevent crazy infinite loops.
However, that functionality would be awesome for a couple use cases:
Subscription businesses - generating regular shipments, doing a monthly reset of quota-based usage, etc.
Yeah, this is a bit scary for us, so we don’t support it yet. We’ll add a proper recurring scheduler at some point, but right now we’d rather have users find other ways to do this.
This is something I hope becomes a feature. I use Parse (or say I used to use Parse until their shutdown), which allowed me to schedule recurring background processes. Inadvertently running too many workflows could be a problem if you aren’t careful and don’t check your work, but I don’t think it will be too much of an issue if you understand that excessive use could cause a self-inflicted DOS attack. Maybe leave a warning to users when making recurring API calls or imposing limits to its use initially.
A bit off topic, but related to the workflow API:
Another feature that I really liked in Parse was the ability to access objects when they are saved or deleted from the perspective of the system. In other words, when a user creates a new object, modifications can be made to it using the “master key” as opposed to the user level. A concrete example for social media would be when a Like is created, rather than update the count on the Post or Comment, have the API workflow pick it up automatically and adjust the Post or Comment there. This saves from having to duplicate workflow events and API calls.
Would it be dangerous every hour, as the minimum duration btw two WF ?
Both @vlad 's use cases are > week. Those I’ve got in mind are a daily workflow to send reminder emails if needed, clean products’s stock in the database every day, calculate every month key metrics for sellers as a sum up (since GROUP BY function is not available).
Mine has now been running every minute for 716 minutes.
I think the issue is maybe more about something spawning more than 1 thread and growing. I wonder if there is something we can do to have these sort of threads limit themselves. So if another one comes along that has the same “id” (?) it will stop itself.
We just enabled scheduling an API Workflow from another API Workflow, with the constraint that we can’t have loops. So now you can have an API workflow the schedules another call later. It probably won’t help your case here, but just wanted to make the announcement
Thanks for checking it out for me, man. Mind putting something in the forum app for me? I’m drawing a complete blank here as to what I’m doing wrong. My zaps are completely unresponsive when the API workflow tries to run them.
