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.