@AnkurGhosh -- this is fantastic, thank you for sharing this new course! I especially appreciate that this was posted prior to the GA planned for January! 

Quick question -- can you answer the question of how many queries we will be able to add when they are released? Given that we can currently build out multiple queries in the current advanced program builder, if we are limited to only one query in the new dynamic JOs, that will be a disappointment.

Happy New Year!

@AnkurGhosh, @ssamarth, is there any update you can share on when we might expect to see the January update to the new dynamic JO that will add queries to the available sources, as well as any other GA release updates?

There’ve been some questions in the GGA Slack community, trying to get an answer to take back to my team. 

Thanks so much!

@james_whitehead any thoughts here? 

Hi dayn.johnson

Thank you for your feedback on the Advanced JO Program course. 

The next release in on feb 10th. Query building will be part of that release. The release communications will be sent to all customers in the next 2 weeks. 

Thank you @AnkurGhosh!

@AnkurGhosh -- this is fantastic, thank you for sharing this new course! I especially appreciate that this was posted prior to the GA planned for January! 

Quick question -- can you answer the question of how many queries we will be able to add when they are released? Given that we can currently build out multiple queries in the current advanced program builder, if we are limited to only one query in the new dynamic JOs, that will be a disappointment.

 

Hey @dayn.johnson! I know this is a bit late, and you may already have the answer, but the new Dynamic Programs are limited to one source per program (aside from uploading a CSV in addition to your Query, Data Design, etc). The thought process behind this was to prevent needing to map fields. Hopefully this helps you, or anyone else who needed the info.

Thank you,

Brian Holmes

Thank you for the response, @bholmes! 

I’ll drop this link to the idea I created on having multiple queries so you can see the reasoning for why having multiple queries (or other sources besides CSVs) is important for a wide variety of use cases -- and how those use cases are present in current advanced JOs.

I have significant concerns around how those ongoing programs will be converted to the new dynamic JO when the switchover comes later this year.

In short: having multiple queries allows us precise control over when and how frequently different audiences flow through a program.

For one instance: a communication sent regionally at noon, M-F to audiences in the Americas, EMEA, and APJ. If we set the program query to pull participants for EMEA at 7 am EST, Americas at 12 pm EST, and APJ at 12 am EST, that program will end up sending to participants in APJ at noon on Saturday (and won’t start sending until Tuesday at noon). Not to mention, we have to rely on wait timers like below.

We currently have the program launch, and schedule the queries at the times and days we want the participants to be brought into journey. Note -- this also allows us to start and stop bringing participants into an active program without needing to stop and clone a program, which is something the new JO doesn’t allow for.

While I understand we can utilize a timezone field in the new JO, we do not have that data available, nor do I foresee that data becoming available in the future. @kstim, can you confirm on the timezone field?

Scheduling different queries for different times/dates is only one aspect. @heather_hansen, @sarahmiracle, @mobrien14 all shared additional use cases in the above-linked post.

@dayn.johnson I understand that need, for sure. I will also say, as it stands right now, the new JO has you schedule the program, not the participant sync, like the old JO did. So the execution schedule for participants would be the best bet, maybe using a rule to fill in a time zone field based on location? Kind of annoying and roundabout but it may work?

Unfortunately we don’t have accurate location data available. The closest approximation to that is the billing country code, but that doesn’t work when so many of our clients have a distributed workforce.

Ex: our billing country is the United States, but if we sent for that, all of our employees outside of NA would receive the communication outside of their working hours.

Billing state doesn’t work for NA-targeted programs either, for the same reason. Ex: if we wanted to send a communication about an event in New York to users sitting in the surrounding states, anyone working at companies whose billing state was in those select states who was located many states away would also receive that communication.

This makes sending any sort of targeted or timezone appropriate communications next to impossible, hence why we send for regional approximate times.

Yeah, that makes sense. I’m not sure of any way around that aside from having multiple programs which is annoying to manage, for sure. With the lack of field mapping as well, I don’t know if multi-source participant lists will be coming either.

It is manageable through conditional waits, but it needlessly complicates the beginning of the program.

See below for the logic workflow I built out when I was testing the beta for the dynamic JO for our use cases. The logic below assumes a program that runs at midnight EST to send at regionally appropriate times. The weekday check (on the right) is in case there are multiple email steps that would cause a participant to receive an email later in the journey on a weekend.

Yikes...that’s definitely really complicated, but props for figuring that out! I probably would have taken the easy way out of making multiples, ha!

Hi @dayn.johnson can you provide a little more detail on what the “Check day is weekday” evaluate step is actually doing? Thank you!

So I don’t think that evaluate setup is necessary anymore with the Action Execution Schedule feature, but essentially it checks whether the current weekday (via a calculated field) matches the day in question, and then waits the appropriate number of days. We use a variation of that in our current advanced (old builder) programs to make sure the current day is a weekday before the subsequent email step.

That is very helpful, thank you!