I’m newish to backend workflows so I suspect there’s a learning curve here. Here’s what I’m trying to accomplish:
I want to be able to send an email to any Users who meet specific criteria (for example, people tagged a specific way who haven’t received this type of email in X days and haven’t unsubscribed from this email type). I thought I’d need to set up a backend workflow that runs based on finding Users who meet that criteria, not based on a workflow action that schedules an email to send (since this should also apply to users who haven’t been back in a while). I expected this workflow would run every day looking for Users who meet the criteria and sending the emails automatically.
I’m not sure which of this logic (likely the unsubscribe check and designating email templates) would be handled with my SendGrid plugin vs the backend workflow setup.
If they’re for something like a newsletter, then what you want to do is just add the user to a group within sendgrid, so that sendgrid manages all that logic and workload for you, the you compose and send emails from sendgrid to the groups etc.
If it’s something dynamically related to their account, like, you have a new message, then you want to be sending that from bubble
Hope that somewhat helps as a way to think about it?
You can use backend database trigger change for this…your conditional should be similar to how you phrased it. The idea of database trigger change is going to be based on the user getting tagged, so you use the condition on the trigger to reference the type of tag that is required to initiate the workflow…you can also add to that conditional or put a condition onto the send email action for the portion of has not received this email in x days. On the user data type, you might want to save via a data field the date that the email type was last sent to properly construct the condition.
Great part of database trigger change is they run only when they need to, based on the data getting changed in the database and the conditions you put onto that trigger.
unsubscribe check and email templates is the workflow actions provided by the sendgrid plugin and you incorporate those into the action series you create for the backend database trigger change
I don’t know if a database trigger makes sense for the criteria I have in mind (because data won’t have changed to be a trigger) so here’s a more concrete example we can work through together:
I have a field that logs the last time a user came to my app. I want to be able to send an email to people who haven’t come back to the app in, say, a month. I want this email to send whenever a user in my database crosses that threshold: they haven’t come back in a month AND I haven’t sent them an email to come back in, say, a week or more AND they haven’t unsubscribed from these reminder emails.
Users are of course a datatype but I was thinking I’d need to create Emails as a datatype to track things like when that type was last sent (unless that’s better tracked in some way with Send Grid). I’m not sure how to write a conditional with date-based logic for each user on the backend workflow.
Just my 2c on this but I don’t think this is an ideal approach to user engagement, I think its better to look at what are the pull reasons to bring them to the platform and send those through.
Like if the platform was for looking at photos of different types of animals, and they selected they liked dogs in their profile, sending them weekly wrap ups of top dogs is a great and straightforward engagement process.
If you do want to do your above method then you can run a workflow and filter by users who haven’t been on in X amount of time, but there will be a lot of performance overheads in achieving this fully as you laid out, and I doubt you’ll get great ROI IMO
At the same time you log that, schedule a backend workflow to run in say a month. On the action of send email in that backend workflow put a conditional that is determining the difference between the current date/time and the date on the field that is logged for last time they came to the app to determine if the diference meets the amount of time you want.
Compare dates with comparisons operators and use format as number of days.
I was hoping to be able to run this logic independent of scheduling a workflow specifically because I’d like this workflow to run against my existing user base, for whom nothing was obviously scheduled on their last log in. Scheduling these kinds of flows of course makes it simple for future workflows, but I really would like to be able to independently run a backend workflow that doesn’t rely on scheduling (to capture a much larger group of existing users for re-engagement campaigns).
Here’s how I think I would explain this to myself now that I think I understand backend workflows a little more:
Backend workflows always require a trigger to run. Those triggers can be:
Scheduled to run once as part of a workflow in the app (“API workflow”). Example: a welcome email when a user signs up
Scheduled to run on a repeating schedule as initiated from a workflow in the app (“recurring event”). Example: a weekly roundup of new things.
Initiated based on a data point changing in the database (“database trigger event”). Example: Your Stripe payment processed.
If you have a backend workflow you want to run that didn’t get scheduled for existing users (the use case I was describing), you can use a workaround workflow that schedules it (something like building an admin view with a button to schedule the relevant workflows for existing users).
For the instance I was describing where I want something to happen based on a logged date passing, I’ll have to use a workaround to schedule the workflow for existing users as well as schedule the backend workflow with a relevant user-initiated workflow for users going forward.
Communicating dates passing in conditionals I tend to find awkward but here’s how I’ve set one up to (I believe) send once the “last updated” date logged is 6 months in the past:
I chose this conditional method over scheduling a specific date to send with an action because things can change within 6 months and I didn’t want to build logic for canceling and scheduling email workflows repeatedly.
I also log each email send since SendGrid limits the history they store and I want to have a record of what emails are sent to which users (that’s the second step in the screenshot of the workflow).
