Bumping this to the top for more visibility!

1. How often do you have a use-case to create different schedules for different sources in the same program?
   Currently none, but if query sources within a program could be copied, it might solve the use-case of regional variances, so a US query and an EMEA query and an APAC query could exist within one program and the source schedule runs by the local timezone. Currently, each region we support has its own program with the only difference being send time, and the countries included in that program’s query. 
2. If we have a single schedule in a program on which all the sources are refreshed, would it work?
   It should be an option to schedule recurrence at the program level vs the source schedule
3. Is it confusing for you to understand the relation between source schedules and program publish and how/ when the participants enter the programs? 
   No

Bumping this to the top! Need more inputs!!

I’ve encountered a number of situations were timezones impacted the number of queries or programs needed. Additionally, there have been a situations were a new customer journey was syncing in the AM and the PM in order to capture new customers as opportunities were closed.

1. How often do you have a use-case to create different schedules for different sources in the same program?
   Very often. This is our default for sending out comms to 3 different global regions at appropriate local times. 
2. If we have a single schedule in a program on which all the sources are refreshed, would it work?
   No, we would prefer to keep the functionality of multiple schedules within a single program.
3. Is it confusing for you to understand the relation between source schedules and program publish and how/ when the participants enter the programs? 
   No, it is not confusing, and is an appreciated feature. I like to publish a program knowing it will sync at it’s scheduled time later in the future. For example, published a program on a Friday before my time off knowing the sources would sync on Tuesday and I didn’t have to worry about it while on vacation.

Thanks for all the valuable inputs.

I know there have been advisory boards and this is top of mind, but this is so desperately needed. I just spent an entire day replicating (2x) every program so that we can send across the three major regions locally. It’s redundant, manual, and will be difficult to manage over time as new programs are introduced and existing programs are modified, it’s simply not scaleable. 

@kelly We are working on supporting different timezones as part of JO redesign. When you separate the contacts out into different regions, what data do you base that on typically? Trying to understand if it’s possible to reliably derive what timezone applies to each contact, and if not, would that have to be a manual input when building the program (e.g. if contact → region = ‘x’, use timezone ‘a’).

@manu_mittal I think everyone’s source is going to be different, but likely a field on the account or contact record. In this role at this company, it’s Sales Region. In previous roles, it was account country. In my experience, timezone at the contact level is difficult because location details aren’t generally collected for contacts.

Rather than Gainsight trying to develop a way to support timezones (which are generally way more granular than ‘regional’ sending), I’d much rather JO functionality be improved to allow for either duplicating participant queries and/or allowing for drag and drop steps on the canvas, so that a conditional wait can be the first step and the admin has the control over the timezone designation/sending.