New Dynamic JO Should Have Multiple Queries (just like older advanced JO)

I have been holding off on using the new JO Experience until the query builder was available.  To hear that I will only be allowed one query is disappointing. I have some additional use cases for multiple queries.

• We have accounts assigned with AMs and CSMs and accounts with only AMs.  So, in cases of some programs, I need to send from the CSM, and if there’s not one, the AM.  For those programs, I use 2 queries within the same program.  The first pulls the CSM when there is one, and the second pulls the AM when there isn’t a CSM.
• We have programs where we want to send to a specific contact if there is one, but if there’s not, to send to another contact.  For that instance, I also use multiple queries.  The first to pull the desired contact if available, and the second to pull the additional contacts if not available.
• I also have programs with multiple queries when I need to run the program more than once a day.  For example, our Support survey needs to run as often as possible to capture new closed cases, so I have multiple programs with multiple queries scheduled an hour apart to accomplish.

I could clone the program and use that to accomplish additional queries, but that leads to:

• Instance bloat
• The need to combine reporting across programs meaning I’ll have to build out custom reporting and potentially use Data Designer again causing instance bloat.
• More complex queries to account for the participant potentially receiving the email from the original program.

PLEASE bring back the ability to use multiple queries in ONE program.  It’s beyond frustrating to have existing capabilities removed and be forced to figure out new ways to accomplish the same task that create even more work.

Please please please allow for multiple queries in a single program. This is extremely important for ours and many others’ use cases!

@vijay Tagging you here

It’s disappointing to hear this limitation. Why take away functionality that works so well already? I will continue to use the original Advanced Programs builder until Dynamic Programs has full parity and more. Taking away functionality is not an improved user experience.

Use Cases

• Setting different schedules for different groups
• Separate out segments based on different sender criteria (as Heather outlined above...segments of customers are serviced differently and need to reference different mapped tokens)
• I know that Timezone functionality is available now in Dynamic, but I’m very unfamiliar with how that works. If an instance isn’t optimally configured for utilizing this feature, having multiple queries for a single program is a great workaround for accommodating timezone needs

Echoing all of the above comments! An additional use case:

For our Professional Services projects, we have a Primary and Secondary contact field on the Salesforce object where our consultants identify the two main stakeholders in an implementation/migration.

Both of these contacts need to receive emails/CSATs from the program, but because you can’t select multiple ‘Email Addresses’ from a single query, we have one for Primary & one for Secondary and map the respective email fields. 

@mobrien14 GREAT call out of that use case -- we have the same use case.

The PS Project object has three fields for survey contact (Survey Contact 1, Survey Contact 2, Survey Contact 3). We have three separate queries to gather each of these contacts as their own participant record and associate the related company and project details to their participant record.

Despite the fact that we won’t be able to have multiple queries, we’re still moving forward with the adoption of the new dynamic JO for our recurring programs once this release hits. I’m reserving judgement on whether that’s good or bad.

For our use cases, having the ability to use conditional evaluate steps without having to rely on skip logic to build in multiple paths in one program outweighs the limitations of only having one query.

I’d rather schedule most of our recurring programs (lifecycle journeys, etc.) to run at midnight in our local time zone, and have wait steps for each global region that are a logical number of hours after the program syncs, and be able to have multiple paths.

For simpler one-time sends (or recurring monthly emails such as newsletters or CSM outreaches) that are more send-time sensitive, I agree with @sarahmiracle. It’s likely we’ll wait to start sending those through the new dynamic JO until we are able to actually schedule exactly when we want specific queries to run, rather than hoping for the best with conditional wait timers.

For clarity/more information, the following is the content from this post (referenced above) -- I was unaware that as it was a post made in one of the groups for the dynamic JO beta, it would be unable to be viewed by anyone not in that group. I’ve included all of the replies to @alizee’s original post as well.

I hope this is helpful!

Original post: Allow multiple sources in new JO programs

@alizee 
Currently, it seems that we can only have one data source per program. It would be great if we could add 5 (or more) sources like we can in advanced programs.

Simple example: 

I have segments by role and sometimes I need to send a program to two roles. Should I have to create a combined segment? I sure can, but couldn’t I instead combine several segments? 

Complex example: 

I want to send emails at different times of day for different regions. I should be able to have several sources so each source can run at a different time (at a suitable time of day instead of weird o-clock). I may not have gone far enough yet though.

9 Replies

@rgupta91 

@alizee I believe most of that functionality has moved to the evaluate step. That’s at least what was mentioned on the call last week.

@alizee 

Hi @rgupta91 Thanks! I don’t see how the evaluate step would decide when to send since we can indeed take a participant field of region, but we cannot set a time at which the email sends. 

@rgupta91 

@alizee would a delay step help?

@alizee 

rgupta91 wrote:

@alizee would a delay step help?

Technically, it could but there are so many issues with this: 

1. JO contributor would have to calculate how many hours after Australia they want to send something which is a bit trickier than specifying the time of the day to sync the participants on. And everything will now have to schedule on Australia time when none of us are there.
2. In that scenario, I think we also will have issues with Evaluate recurrently (not in the below example which should be evaluated once whenever a participant joins since it’s a Regional evaluation) so long as it’ll be checked every 11 hours because we cannot predict (or we can but it’s a mess) what time of day something will be sent. It should be 12 hours which would make it more predictable and easier to figure out. 

@alizee 

Another challenge also just crossed my mind on this inability to have separate participant sources: 

Since we can only have active 5000 participants at any one time, having to sync them all at the same time will cause the 5001st and above participants to sync will be in review state. 

Once the first 5000 participants have been purged, they’ll become active and go through the journey as planned for participants that were added per the participant schedule. Which means the wait timers will no longer mean anything.

@dayn.johnson 

Absolutely agree with everything @alizee posted above!

We have over 10k users, so if we are sending an operational email to everyone at one time, that program will be hamstrung.

We also have multiple programs (many that are only one email) running three (or more) queries, based on global region (Americas, EMEA, APJ). It would not be convenient to have to set out the various time calculations to send them at an ideal delivery time based on time zone -- it’s much more convenient to be able to schedule each query to run on its own timer within a single program.

@Elana Cipin 

My #1 pain point with old JO is having to re-build my query for every time zone. This can take hours for some programs with more complex queries. I thought the benefit of being able to pull from the DD was to not have to re-build it for different schedules.

I don’t think it’s practical for me to use advanced JO until there’s a reliable way to schedule based on time zone.

@alizee 

@Elana Cipin In Advanced JO you can also use DD to not have to rebuild your queries for each timezone (or at least only partially, limited to first Fetch task). The trick is to schedule the DD to run in sequence with the JO query. 

@dayn.johnson 

I seem to recall there being talk of a new query builder as a source option in the new Advanced JO that may be available in one of the upcoming releases, but unsure as to the delivery timing on the roadmap, and also whether we would be able to have multiple sources (or multiple queries).

Thinking our team’s best option for pulling participants into the new Advanced JO will be to create a few segments that encompass our typical recurring program groups, like so:

• HTML + Live Link Communication Type
  • All Active Users
  • Users Unengaged > 30 days
  • New (or mid-cycle) Users (onboarding communications)
  • Highly Engaged Users (active in community, training site, etc.)
• Plain Text + Defanged Link Communication Type
  • same segments as above, so we don’t drag down engagement metrics for those programs

As far as scheduling for time zones, since there isn’t a proper time-zone option right now, our thought on the current best option is to schedule all of our segments to sync at midnight (we’re EST, or GMT - 5), and then have an evaluate step with multiple wait steps that send to the various regional times based on a set delay.

Not 100% sure how that might affect any subsequent email timing, especially if there were delays to when the emails actually got sent. But it wouldn’t look great for an email that was sent on behalf of a CSM or a training/community manager to be sent at 2 am.

Agree with the above! And thanks @dayn.johnson for giving visibility to that post of the Beta Group.

We are still running most programs in the old JO, I can’t understand why they are taking away functionality that was already working and quite well... disappointing UX 😞

Absolutely, @romihache! Didn’t want to leave that good discussion siloed!

And hugely agreed on the functionality. I’m in the process of building out a JO conversion log, and will definitely include a “multi-query dependent” field as I look into converting existing programs (or building out new programs). The more I’ve hear from the GGA Slack community today (first weekday post-release), the more I’m thinking that this may be a slower conversion to the new dynamic JO than I previously expected (or hoped).

I can still see us using it for net new programs (not send-time sensitive) that would benefit from multi-linear journeys, but a key part of my process now in planning any new programs over the next few quarters will be evaluating whether the program can be built in the new dynamic JO, or whether it should still be created in the “old” advanced JO.

@vijay visibility on this

This is a feature regression compared to the old advanced JO, echoing the sentiment from other admins cloning JOs to achieve different segmentation is additional assets that shouldn’t be required.  Additionally, as Gainsight looks forward, how would it anticipate to migrate JOs to the redesigned JO where old programs utilize multiple queries and the new JO doesn’t support this functionality?

Woooahh, @Stuart with the insightful question I hadn’t yet considered! Would love to hear the answer.

​@vmallya – thought of a potential workaround (at least for regional queries). Is there any update on how multiple queries will be handled in dynamic JO (and how our existing JOs might be migrated)?

Thank you for the detailed scenarios on this thread. Sharing a consolidated update on how each of the multi-query use cases can be handled in the new version of JO.

Regional and timezone-aware sending (​@dayn.johnson , ​@sarahmiracle , ​@heather_hansen )  — in February 2024, we introduced the Action Execution Schedule feature in the new version of JO, which lets a program send at the local time of each recipient by reading a timezone field maintained on the participant, contact, or account record. This is designed to replace the need for separate region-specific queries. We understand the concern we have heard from some customers that this timezone attribute is not currently maintained in their data, which blocks adoption of the feature. We do not believe adding multiple queries is the right/accurate solution for timezone-based sending; the scalable path is a single program driven by a maintained timezone field. We would encourage teams to populate this attribute at the participant, contact, or account level so the Action Execution Schedule can deliver the per-timezone behavior this thread is asking for.

Audience segmentation inside a single program ​(@heather_hansen , ​@dayn.johnson ) — for conditional routing such as CSM/AM fallback, primary/secondary contact logic, or standard vs. premium tiers, the recommended pattern is to either use case statements in the query to derive the segmenting attribute - (we also extended case statements to support email data type), or use the Evaluate step to branch participants down different paths with distinct email configurations. Either approach achieves the same segmentation outcome within one program without requiring multiple queries.

On multiple daily executions, with the April 2026 release, the new version of JO supports participant sync multiple times per day, so programs can re-evaluate and enroll new participants at a higher cadence than the prior once-daily run.

Routing to both Primary and Secondary contacts from a single program ​(@mobrien14 ) — we believe this use case does not require multiple queries. A single query can UNION the Primary and Secondary contact email fields from the Account/Company record, producing two participant rows per account (one for each contact), which a single program can then enroll and email. If the contacts are modeled as separate Contact records with a role field, the same outcome is achieved with a single query and a role-based filter. Happy to walk through the query setup to validate this pattern.

Per-segment sender mapping (​@sarahmiracle )— this can be handled within a single program using two supported patterns: (1) an Evaluate step with per-branch sender configuration, branching participants by region, tier, or account owner and configuring each branch's email step with its own sender; or (2) email variants with local header configuration, where a single email step holds multiple variants, each configured with its own sender, and the variant is selected per participant using the same conditional logic. Either approach delivers the segment-specific "From" behavior that multiple queries previously enabled.

Workaround pain and staying on legacy Advanced Programs ​(@sarahmiracle , ​@romihache , ​@dayn.johnson )  — with the capabilities above (Action Execution Schedule, case statements, Evaluate branching, UNION support for multi-recipient queries, per-branch or variant-level sender configuration, and multiple daily participant syncs in the April 2026 release), the scenarios originally covered by multiple queries can now be handled within a single program. Teams should no longer need to maintain parallel programs or maintain multiple queries as source to achieve this behavior.

Migration from Advanced JO programs that rely on multiple queries (​@Stuart , ​@dayn.johnson )— ideally, with the patterns outlined above, a new single query can be authored directly in the new version of JO to cover the original multi-query scenario. For teams who would prefer to carry forward their existing query logic, we are solutioning an option to migrate selected queries into the new version. Further details on the migration path will be shared as the scope is finalized.

Please continue to share any gaps you encounter against these patterns, and we will keep this thread updated.

​@vmallya thank you for this update.  I have provided feedback via the Product Council that I do not believe is covered in these new workflows.  Are you also considering the Product Council feedback, or should I also document here?

Yea, I like the update would would have appreciated acknowledgement of the continued gaps we already brought up with you in product council, rather than making it seem like this issue is resolved. We got a lot of great individual features, that are slowly replacing one functionality (while adding some additional capability along the way).

​@angela_domenichelli and ​@bradley, your Product Council feedback is very much on our radar and shaping where we take this next. We are coordinating a working session with the Product Council in the next 2 weeks to go through it together and make sure the remaining gaps are fully understood.

I have intentionally kept this thread open rather than marking it Released, because we do not consider this resolved until we have worked through your input with you. 

Great to hear, thank you!

Appreciate the feedback, ​@vmallya! Looking forward to seeing these improvements continue to roll out. I’ve already washed my hands of the old “advanced” JOs, and have been having Claude help me design our programs to work around any potential limitations we might run into.

The benefits dynamic JO brings far outweigh any known potential limitations.