Reduce WU for Scheduled Workflow to send email

[boston85719]

@eric10

My question is if switching to the List instead of the way I’m doing it if anyone knows if it would be more efficient. I have to believe there are smart Bubble people out there who has experience with these types of things who know what the faster option is without me having to test it.

You can check out from the words of likely the most knowledgeable person on the subject with a use case example of an email campaign

@steven.harrington

Example: Running an email campaign

Let’s say you have 20K users, and you want to send them all a personalized email. You may want to log this outreach by updating a field on each User to indicate the last time they were contacted. You can create an API workflow that sends a personalized email and updates this field for a given User (in the screenshot below, we’ve named the API workflow “monthly-email-send,”) and then use Schedule API Workflow on a list to run this workflow on your entire user base.

Generally speaking, I would deduce that simply removing the need to have a ‘schedule backend workflow’ action for a recursive workflow will be a WU savings when switching to a backend workflow on a list because we are charged WUs for a schedule backend workflow action to do the scheduling, so just removing that from the equation would likely amount to a savings in regards to WUs.

Additionally, the way in which Bubble explained the change and improvement to the workflow on a list feature is improved speed/efficiency.

Looking at your screen shots with lots of schedule API workflows, I’d imagine there may be a benefit to bringing those actions within the different backend workflows into the same backend workflow to avoid those scheduling charges will equate to even greater savings.

Also, there doesn’t seem to be any need for the step 2 make changes to user because as far as I can see that is just fetching which user to utilize for the flow, and without seeing the actual backend workflow parameters, I assume the ‘user-list-app’ is actually just a parameter for the backend workflow and is not a ‘do a search for user’, which means, you can get costs savings in regards to WUs by simply removing step 2 and opt to send into the parameter list of users already sorted as you want them by created date, so the parameter list is already in the correct sort order and just reference the parameter list:first item in all the actions that need that user.

However, when you populate a parameter as a list of things for a recursive backend workflow, every single ‘loop’ of that recursive flow, you are charged for fetching, each time, the list of things that is the parameter. So, lets say you have 1,000 users in the list that is a parameter, on run 1, you get charged for fetching 1,000 Users, then on run 2 you get charged for fetching 999 users, then run 3 charged for 998 users and so on. That is again an area of cost savings in terms of WUs for using backend workflow on a list instead of a recursive flow.

BUT, the workaround I found for avoiding these charges of fetching the entire list of things for each ‘loop’ of the recursive flow, is to instead of sending in a list of things, you send in a list of text which is the unique IDs of the ‘things’ then you have a step, like step 2, where you search for that thing via the unique ID (coming from your parameter of type text) so as to only be charged for fetching a single things for each loop of your recursive backend workflow.