have been struggling with different ways of addressing a particular use case and after building-out (and deleting) different options i thought i’d just ask the community:
Users can borrow Items and if they don’t return an Item by the dateDue, the User’s related data type AccountBalance gets automatically booked with a fee depending on their membership type (on dateDue+1 API workflows run if dateReturned is empty).
now i am trying to build an easy way to pause the charges (e.g. when we’re closed for the holidays) so that anything that comes due during that period just gets rolled over without a fee being booked (just sets new dateDue).
so first i added a new data type (FeePause) with fields feePausePeriod (date range) and feePauseReason (text) and the ability to enter this on the front end and added a Do a Search condition to the backend WFs to see if Current Date is within date range… but that seemed unnecessarily heavy to run a backend search every single dateDue…
so i added another data type (FeePauseFlag) to Do a Search daily to turn the flag on/off and pass that as a parameter to the backend WFs and add a condition when they are scheduled to only run if FeePauseFlag’s flagOn is No and adding another API WF for the case when FeePauseFlag’s flagOn is Yes… but then i thought maybe the parameters sent to backend WFs are fixed at the time they are scheduled…
so i added the same condition to the backend WFs… but then i thought if parameters are fixed when scheduled on the front end then why wouldn’t they be fixed when run on the back end…
so then i thought about just triggering the use case manually on the front end when FeePause is actually entered but i wasn’t able to define a Do a Search for User’s AccountBalance that were modified during the date range feePausePeriod…
so then i added a field to the data type AccountBalance which is a list of dates when the AccountBalance is modified (dateModified) and tried defining a Do a Search for AccountBalances:each item’s dateModified that IS IN FeePause’s feePausePeriod (date range) iow AccountBalances that were modified in that period… but that was a dead end as well… sigh…
so now i’m thinking the manual workaround (changing every AccountBalance directly in the DB or building out admin functionality to sort AccountBalances by date modified and manually triggering credits) maybe isn’t so bad if nothing better works (urgh)…
so my questions:
- In general is it better to trigger something through the front end if possible vs. using a back end API workflow?
- what’s the difference between setting a When condition when Scheduling an API workflow in the front end vs. setting a When condition on the API workflow itself in the backend vs. both?
- do parameters sent to backend WFs get ‘frozen’ when scheduled? or should it work to send the FeePauseFlag as a parameter and when the backend WF is scheduled to run it will look up FeePauseFlag’s flagOn on Current Date before running…?
Many thanks in advance
It depends on the use case. Just need to consider the differences between the two to draw a conclusion of which is better for your use case.
Put the condition on the scheduling of the API workflow, if the condition is not met, the backend workflow does not get scheduled. Put the condition on the backend workflow itself, then the backend workflow will be scheduled but only run if the condition is met that is set on the backend workflow…so basically, think about costs of WUs for scheduling a backend workflow.
I would hope that it is using the details of the date the backend workflow actually runs, and not when it is scheduled. I do not know this for sure, so you could reach out to Bubble support to ask them directly to get a 100% accurate answer.
In terms of your overall issue, I would think that if you know for sure the dates you are going to pause the fees and instead roll the due date forward to match the dates of when the pause takes place, why not just run a workflow that is scheduled to take place just a few moments before the pause period begins, and that workflow will search and find all due dates that fall in the range of the pause period and update all those due dates to be equal to the pause periods end date?
Move to the backend if:
this workflow runs or will run frequently
this workflow grows and has many steps
this workflow works with sensitive data
this workflow uses many filters and sorting with a big database.
was originally reluctant to mess with the already scheduled API workflows based on those due dates bc of recursively scheduling new API WFs (recursive=eeeks), but on paper it does look like the cleanest solution so thanks for that : )
thanks for the feedback : )
Another small implication here - the condition at point of schedule and condition at point of run could be different.
Suppose Current user’s name is George.
We have a condition only when Current user’s name is George on both the schedule action and the backend workflow itself.
If we schedule the API workflow to run in 10 minutes, it will schedule. But if I change my name before that 10 minutes, the workflow will remain scheduled but it won’t run because the condition isn’t met.
Yes. If you send Current User’s name, you’re sending a text. If you schedule the API workflow with a text parameter that takes Current user’s name when scheduled and the user changes their name between the point of schedule and point of execution, it’ll still use the old name because that’s what was sent to it.
However, if you send a Thing it will use the latest version of the thing. So, let’s now say a backend workflow takes a User parameter. We’re actually just passing a unique ID here behind the scenes.
I schedule the workflow, then change my name on the User type before it runs. sun the backend workflow, I reference that field through User’s name. So, Bubble uses the User (unique ID) parameter that we provided to get the User from the database, and find out their name. Hence, when sending a thing to a backend workflow and referencing it within the workflow, it’ll always reference the Thing at the time it ran rather than the time it was scheduled.
Hope that helps.
yeah that help clarify things, thanks : )