Is there a way to have a pause before the next step in the backend?
I am trying to create an email sequence, so being able to send an email a day after would help.
Is the best way to just schedule the same api as the pause function. Then simply put in a field that lets the system know it already sent an email so it knows to move on the the next?
No, your terminate workflow action has no condition so it terminates the flow every time.
Try just using another backend workflow that when you use the schedule api workflow action you schedule it for current date + whatever pause you want as number of seconds, minutes, days etc.
Well if I have multiple emails in the WF, it would schedule the api but continue to the other WF right? If so, that is why I am terminated the WF so it will stop there. I will then put in some conditional on the Email that was sent already, the schedule api that was already scheduled and the terminate wf. That way it skips down to the next email.
It should be like that right?
No, because you terminate workflow action has no conditional on it so every time that action is executed the entire workflow is terminated and no subsequent actions would ever run.
Your step 3 is a terminate workflow action with no conditionals on it.
Setup a a schedule backend workflow action with the schedule date to current date time + 1 day to schedule itself. Use one email action and one schedule action with condition that if the email was already sent to not send and not schedule again.
You are basically building a recursive backend workflow to run after one day and conditionally stop running.
Sorry the current picture does not show what I was talking about doing. I was just explaining in text what I believed was the right way to handle it.
This picture is more of what I plan to do. Change the email_to_run number for each scheduled API call. This way it runs the email it needs and just end the flow and come back a day later to send the next email.
I guess with the conditions I do not need the terminate WF. Because it will just not run the other emails. But if I plan to have 10 emails in this WF, would it be best to still have it. That way I am not using WU for bubble to check the condtions of the other ones that I know do not need to be ran. Or does it not consume much WU for bubble to check conditions on WF?
From the screenshot above, a more simple way to write this is to avoid having the same three workflow steps for each day of the sequence (hardcoding it so you end up having 60 workflow steps if you had 20 emails).
You could create a database table with a row for each day in your sequence. Then control it dynamically, e.g. it keeps going until each one is sent.
In this situation, I’ve used a List of field “To Send” and a List of field “Sent”, and you move each email between the two lists as it is sent. It’s a nice way to see where each person’s emails are up to in the flow.
Doing it dynamically, you can add or subtract emails in the sequence and this automatically flows through to the app, no need to push changes every time you change the sequence.
Hey, is it possible for you to show this visually? I am a little confused on this part, “You could create a database table with a row for each day in your sequence. Then control it dynamically, e.g. it keeps going until each one is sent”.
Also, this is what I have currently:
@boston85719 hey any idea on how to set up what Will suggested? I am confused on how to get the backend to send emails until it goes through the list without making it recursive.
Hey @sheepherd.co
It’s a bit tricky to explain here.
I can set up a coaching call with our senior dev and he should be able to set up a basic proof of concept in an hour or two with you. Then you can implement it in your app. DM me if you would like.
So based on screen shots, which from previous messages seem to not be actually indicative of the actual setup, it is hard to determine exactly what you are trying to do.
From screen shots I see you scheduling the same backend workflow multiple times which is called ‘nuture-to-onboarding’ and then an option set with 10 different options called Onb Nuture 1 - 10.
What I can assume is you are attempting to use the option set to save your email templates, and plan on sending 10 different (and I mean actually different content in the emails) in an order until the user actually follows the onboarding process.
One thing to note, users do not like being pestered. I had a client who wanted to send multiple onboarding emails to persuade users to signup. I cautioned them against the number of emails they would send, but my advice was not followed. 3 months later I had to change the number of emails sent based on angry ‘user’ feedback of being bombarded with emails, so the point here is I’d recommend not having 10 different emails and perhaps at most 2-3 with a fourth that can be a month later as a sort of last attempt.
In terms of how to set this up if my assumption is correct that you want to go through a list of options that are basically the email content as templates (yes, an option set can be a template for email content if done properly by using things like {{user_name}}for placeholders of email content templates that when in a send email action will have find and replace for all the dynamic content to be replaced. So you can very easily have an option set with attribute called ‘email content’ and your send email action will have a dynamic expression of ‘option Email Marketing email content: find and replace’ so that your backend workflow uses only one send email action and not multiples.
Then the backend workflow will have a counter parameter that literally, just counts between recursive sends (and keep in mind recursive is not just one after another with no delay, it can be a delay of 2 days, 5 days, 7 days, whatever you want or need it to be). Your option set needs other attributes, like one called ‘days_delay’ that will be of type number so that when you are scheduling the backend workflow to run again, you use the next in line option days_delay value in the dynamic expression for scheduling to run. You would also want an attribute that is a ‘sort_number’ to know the order they should be sent in.
So, now, you have a backend workflow with parameters of ‘current option’ which is the actual option value, a parameter of ‘number_of_runs’ that is just tracking how many times it was run, which is tied into the attribute of ‘sort_number’ so as to pull up from option sets the correct option for the current run number (ie: run 2 will have number_of_runs equal to 2 and option set is filtered by the ‘sort_number’ which should equal the number_of_runs).
So you do not need to run through a list really as there is no list to run through other than the option set, and you do not need to do any searching or anything like that.
To ensure you do not continue to send emails unncessarily, you will have conditions to terminate the workflow as step 1 if the user field indicates they have been onboarded. This makes tracking the scheduled workflow id inconsequential, and so removes any need to touch your database at all and still know that the backend workflow will stop running when it should. And to help ensure that, you can have a second step of terminate this workflow conditionally set to if the ‘number_of_runs’ parameter value is greater than Get all options count value, so if you choose to add into the option set a 4th or 5th email, any currently running recursive backend workflows will run for those newly added 4th and 5th emails as well.
Okay thanks for that! Yes you are right on your assumptions. I am actually using Mailersend for my emails. So I I have the {{user}} set up in my templates.