This idea is very similar to this post by
As the title says, there is a very popular use case for having multiple queries within a single JO program: multiple queries allow us to have a much higher level of control over the time different audiences are brought into a program, without having to calculate and rely on wait steps (and trust them not to misfire).
Most of our programs in the advanced JO have multiple queries (usually three): Americas, EMEA, and APJ. We use the Global Region field to determine the send time for those recipients, as neither a timezone field nor a billing country are reliable methods of determining when to send an email, and having a CSM emailing a client in the middle of the night doesn’t lend to the idea that the CSM is emailing them.
We also have some programs where we have slightly different audiences (standard support clients, premium support clients) receiving monthly check-in emails, and each of those audiences uses a different query, but is still part of the same program. Bringing both of those audiences into one program and then having to filter through conditional evaluate steps will further complicate things.
We prefer to use queries in our programs to have a higher level of control over the audience and the send time. Please consider allowing us to include multiple queries, just like we’ll be able to use multiple CSVs.
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.
I could clone the program and use that to accomplish additional queries, but that leads to:
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!
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
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.
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.
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.
...
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
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
@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.
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.
@alizee would a delay step help?
rgupta91 wrote:
@alizee would a delay step help?
Technically, it could but there are so many issues with this:
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.
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.
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.
@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.
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:
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.
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?
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.