Looking through this all now - will come back to you shortly with a simplified workflow based on using recurring workflows. This will cut out the ‘daily_reminder_check’ workflow and more or less replace the ‘schedule_reminder’ workflow.
This is how push notifications work in the first place - users need to subscribe to them to receive them. Have you set it up anywhere in your app for users to be prompted to receive push notifications?
Thanks for the screenshots, they were incredibly helpful to understand what you’ve got setup. It wasn’t quite right but as you pointed out before, my instructions weren’t immediately clear what was a backend workflow and what was something that took place on the actual page. I’ll tidy this up now so if you need to revert back to that structure, you can.
What I’ve done is rejigged the workflows so that we’re using recurring workflows (and therefore at least you’re starting from a foundational setup that supports any timezone).
1. send_reminder (backend API workflow)
Everything is correct here except obviously the fact that OneSignal isn’t sending a notification but this is a separate issue that we can address once we’ve got the overall structure sorted. If you want, you can replace it with a send email action for now to make sure that we can effectively test.
2. ‘schedule_reminders’ (backend recurring event)
What we’re doing here is just defining the event that needs to be triggered on a daily basis.
3. Scheduling this recurring event (on your dashboard page)
What we’re doing here is scheduling the recurring event to run every day at 12am.
And you’re done (at least for the underlying scheduling structure). You can now delete the ‘daily_reminder_check’ and ‘schedule_reminder’ API workflows - they aren’t required.
I don’t believe i have i thought that what we have set up WAS to receives notifications (keep in mind i am new to software and am not a technical person).
Will go through this now
No worries, so what we’ve done is built a system that schedules reminders - no issues there.
Think about push notifications like subscribing to a mailing list - the user has to give you permission to send them in the first instance. If you look at the OneSignal plugin, the first action is to 'Show notification prompt. Might be good for you to test that out on a hidden page and understand how it works. Once the user accepts the prompt, then you are able to send them push notifications through OneSignal.
No worries, I’ll be around for a few hours. Also your setup to get the popup showing when they get to the dashboard looks correct - that should work just fine.
Hey, i have set up as you have detailed but didn’t get an email at the time the use (myself) selected.
I don’t know what the problem is so i don’t know if these two images will help reveal anything or not.
edit: thanks again for your help Juice
Wait, am i supposed to have some email address attached to it to send an email FROM? who would the email be coming from? lol
Yep, so the reminders will only kick off from tomorrow. Check the logs again tomorrow morning and you should see another workflow scheduled to send the email - and hopefully, send you the email too!
If you want to test it today, then you’ll need to set the recurring reminder to kick off at ‘Current date/time’ and not ‘Current date/time + (hours):24:rounded down to day’ (step 3 in my instructions above).
Unfortunately it’s not working still, i changed it to start today and set a new reminder for 2:35 but didn’t get an email. I wonder what’s going wrong.
Hmmm, that’s unusual - can you include a screenshot of the row in your table that has the reminder scheduled for 2:35pm?
Looks to me from above that you have a reminder scheduled to send at 7:15pm which makes me think that the recurring event is working correctly, but there’s just an issue with the actual sending of the reminder email.
What do you have in your server logs around 2:35pm? Any errors?
Okay perfect, so the workflow is definitely working as expected, it just seems that the email isn’t coming through to you.
Might want to check your junk email folder to make sure it hasn’t got lost there but it seems like it’s working as expected.
Edit: You could also try the SMS action that you had earlier and see if that works?
Damn, it did work!
It went to my ‘Promotions’ inbox in gmail. /:
That’s cool - you can improve deliverability by either subscribing to a paid SendGrid account or other transactional email service such as Postmark or Sendinblue (reasonably popular on the forum).
Ok, so I will now just summaries what still remains to be solved:
It seems that the schedular is showing/still running any prior schedules when it instead should updated itself so that it only ever has one active per user (e.g. if they sent another one). It looks they might be going to 'stack each time (which is not desired).
(may be related to the first point above) I have set another workflow on the dashboard page (an alternative version of the initial one) to make it so that the database is updated with a new ‘reminder’ when they want to set a different one but i’m unsure if this will work properly (e.g. still schedule a new reminder) the way i’ve set it up. There should only ever be one row in the database for each user. take a look at the workflow, it works in that it modifies the users entry with new time/ days of week. i’m just asking if this will still schedule/modify the scheduled reminder.
I still need to change this from email to One Signal.
I need to have the ‘time/date’ selector element be a ‘time-only’ element (you know, because users don’t need to be setting the date, that doesn’t make sense). but bubble doesn’t seem to offer such a thing. Do i resort to a text input for time selection (really?). Would love to hear your thoughts on this one.
Then i would like to send you some $ for your help juice 
Yeah I reckon it probably is. You definitely only want to keep one reminder row per user. If you create multiple, then you will definitely ‘stack’ recurring events on the same person.
Seems like you’re already on the right track, but basically if they click done and a reminder already exists, you just want to make a change to that reminder and close the popup, that’s it. There’s no change required to the recurring event.
Only if the reminder doesn’t exist do you want to go about setting the recurring event.
Yep cool - so you’ll definitely need to add the ‘Show notification prompt’ action to this workflow so that the user can give permission. You should do some thinking about what the ideal user experience is and then work on building that.
I currently use the Air Date/Time Picker plugin (like it seems you do too) and tick one of the settings so that it only acts as a time picker.
This still stores a date in the db (which is fine because the workflow expects that), but at least the user gets the right kind of experience. It’s a bit clunkier than I’d like, but it works.
I haven’t read the message you just sent below yet. Here is what i was gonna add first:
I updated the DB entry (via using the front end). to make a 4:45 pm ‘time of day’ reminder.
…But the scheduler still shows the old one that was set for a 2:25 time. It see that the workflow for the scheduler is only being informed if i delete the database an start again… i.e. if the ‘create new entry only if empty’ workflow runs rather than the 'modify thing, only if reminder isn’t empty
The recurring event runs daily and so is therefore only scheduling ‘send_reminder’ for that day. If someone has a reminder scheduled for 3pm but at 10am goes in and modifies their reminders so it sends at 1pm, then yes you’ll have a bit of an issue on that specific day because the notification will come at 3pm instead of 1pm. However the next day, it will come at 1pm as expected.
Two solves; (a) either inform the user that the ‘changes will take effect from tomorrow’, or (b) you can make an adjustment to the recurring event so that it has a second action which saves the scheduled workflow ID against the reminder so that you can delete it if you need to.
This does however add more complexity because you also need to tackle the setting of any reminders due the day of the change. In the same example above, when you make the change at 10am, we could delete the 3pm notification but you’ll need to wait until 12am the next morning when the recurring event runs again to realise it needs to schedule an event for 1pm.
I’d probably recommend the first solve as an MVP approach and if you feel the need, you can iterate on it later and build more robust functionality.
I agree
