Scheduler Best Practice Design

Hi Bubblers,
I’ve been lucking on the forum for the past month and soaking in a lot of great tips. I have a design question related to scheduling events so it’s time for my first post.

I’m using Bubble for a startup MVP and eventually for our initial deployment.

App overview:
The easiest way to describe the components I’m working on now is like a scheduled survey engine.

Entities: a “user” is a member of a “program” which has a nested structure of entities including type of “topic” Each “topic” has multiple “questions”. "Topics have a defined schedule they are due “day of week”, “time”, and “frequency”.
The end goal of all of this is to have a daily SMS message go out to every user based on the data collection that is due that day. These are tracked as “requests” so I know when they were triggered and link any actions and “responses” to this record.

Objective: Trigger multiple SMS messages daily based on user, program, and topic scheduling data.

Question: I can see multiple ways to tackle this. I’m looking for advice from people that have worked with the scheduling engine to identify the best practice approach. I’m also trying to not exceed the limits of scheduling event frequency so I can stay in the pro license tier.
Options I’m thinking of so far:

  • A daily workflow that queries tables and generated a list of scheduled events for every user’s request for that day.
  • Queue a single request event for each user for the next request that is due. During the processing of that request, calculate and generate the scheduled event for the next request.

I’m open to any and all options. I’d also appreciate any concerns and pitfalls I should be on the look for.

Happy to share more detail or take the discussion offline if that’s easier.

Thanks for your advice.
John

Are people not using the scheduler features or is what I’m trying to do too complicated?
I’d love a little guidance before I spend too much time testing various options.

I think a lot of times more complex questions go unanswered as they are not as easy to off the top of the head explain.

If I were you I’d think about the database structure as that may be an area to help with the processing.

It seems like you want your “User” datatype to have a list of “Programs” (which is a datatype) so that you could find the list of “Topics” (another datatype) that are associated with the “Programs” that are on the list of “Programs” in the “User” datatype.

And you are placing the information regarding the time onto the “Topics” datatype, so that all information necessary to trigger your workflow to send or schedule an SMS message to the “User” is on the “Topics” datatype.

I’d just put the “Topics” datatype as a list onto the “User” datatype. So that you could just look at the “User” and search the list of “Topics” on that “User” to see which “Topics” are due that day.

Doesn’t seem like you need to trigger multiple SMS messages daily, because it should just be one SMS message each day to a user who has a “Task” that needs the questions to be answered that day.

So I believe you could just schedule a backend workflow at the time of day you want the SMS sent out.

Your backend workflow would be run on a list, the list being all “Users” who have a “Topic” with a due date of current date.

1 Like

Thanks @boston85719. That sounds like it might work. I’ll give it a test.