Journey Scheduling: Enhance Start/End Time Precision

[reaper]

Currently, journey scheduling is restricted to daily starts at midnight, which limits flexibility and control over journey triggers.

To address this, we propose extending the "start" and "end" fields to include hours and minutes. This enhancement would allow users to schedule journeys to begin at specific times, improving alignment with workflows and operational needs.

By enabling more precise scheduling, this change would enhance workflow efficiency, support accurate duration tracking, and provide greater control over journey performance and timing metrics.

[pushchris]

@reaper unfortunately the process of checking for and re-entering users to a journey is a pretty expensive process, would have to refactor and find new ways of handling to accomplish this which I don't anticipate being able to get to soon. For now I would recommend adding a delay after the entrance to "wait until time" to keep users from your action until the time you desire. It should have the exact same effect and be much easier on performance.

[reaper]

The problem we have is that journeys are triggered at midnight based on a list computed from attributes synced with our platform during the day. We want to shorten the delay beetween the moment we sync the data and we trigger journeys.

For ex: sync from 1AM (duration around 2 hours) - 6AM triggering all journeys (so we can remove the delay, also)

Do we have a workaround for that with the existing codebase?

[pushchris]

If you are already sending events from another platform could you also send an event like sync_finished or something? You could then trigger the journey to run immediately based on receiving that event. In theory that would actually be more reliable than doing things time based since you don't have to predict how long the sync might take. How are you syncing over the data? If you are posting events to the client endpoint, there is some undocumented functionality that might help you out. The event endpoint also accepts a user parameter that takes the exact same properties as the identify endpoint. If you pass in data there it will update the properties on the user and post the event. If you are just using the identify endpoint right now it would be a fairly easy replacement and get you immediate triggering of journeys based on receiving the data