I ran into this same issue right before the 4th Holiday weekend. L1 Support did not know about this concept, and it wasn’t in the documentation. They directed me to recreate programs from the ground up (when we already had a program started and in progress), so we had to get creative to leave that small # of participants on that program, then create the new program - only to have the same issue. He then escalated to L2 support who introduced this to me like it was some awesome new GS feature.

Incredibly frustrating! 

‍♂️ I think Alfred said it best… 

How did this make it out of Beta? @revathimenon has the PM seen this?

Hi @bradley 

Thanks for looping me in.
I’ve raised it to the team internally on priority. 

Hello Everyone,

We understand the challenges you've faced with the inability to edit queries once a program is active, and we sincerely apologize for the delay and the inconvenience this has caused.

I may not have the best news, but I wanted to assure you that as part of our roadmap we are actively working on implementing the functionality for post-publish edits to the entire program, including the ability to modify query sources, add or delete steps and more. Our initial plan was to release this feature in Q2, July 2024. However, due to prioritizing other critical feedback and enhancements, we had to adjust our timeline.

We are now targeting the release of this feature by Q3, October 2024. I will keep you updated on any interim progress as we move forward.

It's also important to note that the redesigned JO represents a significant evolution from the previous version, resulting in certain features needing to be handled differently. These changes are intended to provide a more powerful and intuitive user experience in the long run, even if the transition period poses some challenges.

We deeply appreciate your understanding as we work towards this goal. Thank you for your continued support and engagement.

@vmallya thank you for the update here!

I can see the dream state, and it’s clear where JO is going. I’m looking forward to hearing more updates as we get closer to this release. Dynamic JO is absolutely more intuitive than the advanced JO (especially considering the “skip logic” needed to use the continue steps for yes/no conditional waits in the classic experience), and while we’ve had to use some workarounds there to meet our current needs, it’s encouraging to see what’s on the roadmap. 

Coming back to this again because it is extremely frustrating to need to make to a change to an existing program with a query and not being able to.  It even goes so far as to let me add in an additional filter, but then, the Save button is greyed out.  The best part is if I click Cancel, it prompts me to save even though I can’t.  Again, there are often times where we need to tweak a query a bit after the fact, and this is making it so much more time consuming to do so. 

A recent use case:
We have a program that was running only for accounts in a specific region, so we had a filter in the query to filter to those specific regions.  An additional region decided that they wanted to take part in the same program.  Instead of just easily editing the filter to add an additional region, I had to clone the program and rebuild the query to also account for participants from the previous program so we didn’t send to them again.  

Very curious here too -- this recent use case bit me when I was rebuilding our ONE dynamic JO to adjust the audience (from one internal recipient to the account team, and from 180 days to 225 days prior to an event). Because those account team members needed to be able to receive an email for each unique account, I was unable to exclude them using the uniqueness criteria (since we can’t use multiple uniqueness criteria in the “Advanced Criteria” setting, as detailed here). 

Thankfully this was just an internal program, and only a few internal participants received the email when they shouldn’t have gotten it, but this is yet another reason I’m still building programs using the “old” advanced JO -- and will continue to do so until we’re able to edit active programs in the new dynamic JO.

Hi @vmallya - are you able to provide an update for this one please? You were targeting October ‘24 previously, has progress been made?

Curious here myself. On the program referenced here below, I ended up cloning the program and rebuilding it using a Data Design (DD) as the source instead of a query. By bringing in the internal reps for ALL of our accounts into the DD, I was then able to use the audience filters in the new dynamic JO to adjust the span to a very narrow date (span > the next x days AND span = the next y days) so that I was able to exclude anyone who had entered previously but needed to be able to enter the program again, while also including our target criteria that was originally in the query. 

That way, if there are any future changes to the original query logic, I can just make those changes in the audience filters.

TL/DR:

Could we please get an update on dynamic JO query editability?

The current process isn’t sustainable.

@silasramsden @dayn.johnson  - sorry for not updating sooner. We have decided to delay the release of this feature to focus on overall quality improvement and resolve the current escalations. We plan to review the feature with a couple of customers and in our council session before releasing it in phases - i’ll share an update here in mid of next month. Thank you for understanding.

Thank you @vmallya, I’ll stay tuned, and will continue my conservative approach to rolling out dynamic JO programs until this launches! 

I ran into this with a JO program this week. It’s definitely not ideal to have to Pause/Stop a program simply to add a filter for participants. Can’t wait to hear this one has been addressed!

Here, here!

As a rule:

Stakeholders (and priorities) change over time.
Queries need to be able to be (easily) changed to keep up.

Until queries can be changed, I’m unfortunately unable to recommend their use as a source.

What’s funny about this lack of parity is old JO didn’t used to be editable, either. It would be good to consider existing functionality or at least consider what prior pain points were resolved and avoid them in new functionality with future releases. 

Yup… certain parts of old JO still aren’t editable, but I’ve accepted that.

We can’t change how a journey is structured (audience > email > wait > conditional evaluate > second email to end), nor can we change the actual template or add in new calculated fields, but we can change things like:

• Query logic
• Journey logic and timings
• Mapping new fields (including mapping strings to email)

So many details to keep track of… what we can change vs what’s locked upon publish.

I’m going to add my experience with Ghosted fields.  I built my first JO in the new builder because I needed the flexibility of the query builder.   Unfortunately, I won’t be using it again.  In the old builder you can see the Company name along with the participant name, email and other mapped fields.  In the new builder after you publish, you only see the Company GSID, participant name and email.  I now have to run a report to provide my users with a useable list of participants and their status instead of just being able to download the participant list from the program.  Extra steps and time that shouldn't be necessary.  An upgraded functionality should keep the basics of the previous functionality at a minimum.  

Cannot agree enough with the above - an absolute waste of time. 

Yup! I have to run my query as a DD in parallel to get a report to review my participants… doubles the time for our renewals program… 

Adding my observations here as well. Our (single) dynamic JO originally had a query source, but we had to clone it, rebuild it using a data design for the source, and relaunch it since we had to make changes to the query after publishing it, and I wanted to prevent having to repeatedly stop and restart that program in the future as more new programs.

One of the side-effects of using dynamic JO is that a new data object is created for each dynamic JO after launch with the participant data. Enter the ghost data issue.

• Our first iteration of the program (query source) has 18 participant fields in the object
• Our second iteration (data design source) has… 2 participant fields

Why is it so difficult to show the participant data on these programs?

If we build a program and include those fields in the program -- we should be able to see those details for program participants. This is where custom field mapping is incredibly helpful in the classic advanced program builder, and is why we can’t justify launching external programs in dynamic JO yet (see the related post below). Even if we have more data available in the show section in the query, we can still control exactly what fields are visible in the participant list by mapping them ourselves.

This is a big challenge for us and each time our stakeholder have a “tweak” they want to something we are having to clone the program to modify a filter or add a field. PLEASE!!!! have this in the next release. Love the new shiny stuff but would love it more if the basics just worked. 

In the meantime, I recommend using data designer which will provide more flexibility, surely filtering would be solved, adding fields as well but it depends for what purpose (how the new field would be used). 

New JO can not be trusted, very frustrating to work with as it seems to have random behaviors and significant core function regression.

Field mapping is so basic and such a constant need, why take the power to configure this away? 

Not only are the basics taken away, the automatic decisions it makes for us are unwanted and often wrong.

Ghosting fields makes reporting much harder than it needs to be, why?

What GS Admin focus group helped decide this products direction? I can’t find anyone championing this - all the feedback is negative.