Historically when you schedule a workflow on an object if you are to schedule the same workflow on the same object again it will cancel the first scheduled date and replace with the new date.
Is this no longer the case or has anyone noticed it working differently as of the last 60 days?
My case:
We have a marketplace app with “posts” that schedules an expire date for +2 mo rounded down when created.
We also have a renew function that hits the same exact “expire post” wf however, within the last 60 days the initial date no longer cancels when renewing and adding a new expire date.
So what happens is let’s say we are 3 days away from a post expiring, we renew it so the new date is +2 mo rounded down. We do log this and can confirm it scheduled but for some reason in 3 days the post is expired anyway.
Same post object and same workflow scheduled 
I personally never have experienced this, likely because I’ve never had a function that would do that on purpose, but in an app where we have things happening live, sometimes we end up needing to manually trigger the same schedule of backend workflow and it never canceled the previously scheduled workflow.
Personally, I would have found that to be a bug because if I had the backend workflow adding values (like literally just addition of values) I’d be likely to schedule the same backend workflow on the same object multiple times and would never had wanted to the previously scheduled backend workflows to have been canceled. So, to me, if this is now the behavior, in that a previously scheduled backend workflow remains scheduled even if the same backend workflow is scheduled again on the same object, it sounds like a Bug fix was put into place.
In the same app where we sometimes had to manually trigger the schedule of backend workflows again, I now have set this up for the client so we do not need to manually do it, and part of that function is to save the scheduled workflow IDs onto the data type, and when scheduling the backend workflow, we first check if the data type has the scheduled IDs empty or not, and if they are not empty, we cancel those backend workflows before we schedule the new ones…this feature is for changing dates of a scheduled booking service which triggers multiple emails and status changes etc. based on the bookings scheduled date.
This for me would sound like intended behavior, and not of the same definition from Bubble engineering, but like a literal intended and logical behavior, because that originally scheduled backend workflow would not get canceled unless the workflow actions are in place to cancel it, so it would still run as scheduled and change the post status to expired.
I’d recommend doing as I had, which is save to the object the list of backend workflows scheduled IDs (at least for me I needed it as list because of multiple backend workflows involved) and when you have the schedule backend workflow action, put in the previous steps a custom trigger to check if IDs are already saved, and if so, cancel those scheduled workflows before the new backend workflow is scheduled.
1 Like
