+1. We frequently need to update queries after publishing, and this is causing us to have to create brand new programs which then complicates reporting and everything else as @Elana Cipin described. 

We have been asking our CSM for updates, as this is a huge pain point and we got this:

The product manager, Vijay, returned a brief response 
"This is a work in progress and we should be making a release in July."

We are lighting a candle praying for that release, we have so many clones just for one program that is a headache to manage...

Wow… and to think I’ve been building a new query in a new dynamic JO. Was really hoping to launch this week, and hoped I wouldn’t have to build this net-new program in advanced JO and migrate it later…

But our date ranges frequently change for this program (and others like it) -- and it’s not worth a individual data design (one-off query to send an internal program).

Could we please get this on the roadmap for a launch in advance of the forced migration? This absolutely should have been part of the original query launch in dynamic JO.

Two steps forward, one step back. 

I literally created a set of folders for new dynamic JOs, so I can create the new programs in new folders and keep all the old advanced programs in a set of “z_insert folder name here” folders as I begin stopping and migrating old programs over.

Talking to our CSM tomorrow, and will be linking this post straight into our meeting agenda!

In the new version, if your participant list is based on a query, that query can’t be edited once it’s active. It can’t even be edited if you pause the journey.

What?!?!??!   This is … essential...

+1… this is killing me… I’m trying very hard to adopt the new JO but every step of the way is a pain. I keep on needing to duplicate programs every time I need a minor change. And every single time it´s redoing all of it, building the logic to avoid spamming users from previous programs, and adding the new program ID to the post analysis… 

That’s exactly how it feels. Query builder was (is) one of the key features of JO but it wasn’t (fully) included in the first launch? Wild that an improved feature is missing functionality that is used left and right in the “old JO” 

Couldn’t agree more with everyone here. This is an essential component that’s currently missing from the new JO programs. I love the new UI, but it’s been such a headache any time there are changes needed to active programs. Please Gainsight, don’t push this essential feature out any further than July!!!! 

Haven’t yet banged my head against that wall, great to find out before I do. Note to self: keep onboarding on a data design. 

This is an absolute must. We have URLs in case expressions added into a multi-step journey and those URLs are changing. So we’re left with the option of:

1. Cloning the JO and using exclusion lists, meaning people who were mid-journey miss out on the end of their journey
2. Dead links in email templates

Both of these have a direct end-customer impact.

Hey @silasramsden Nice seeing you over here . I have had to mitigate similar cases of either changing a program and making sure there’s no “doubling up” on the program (emails being re-sent from scratch) as well as having turnover internally leading to emails being sent from gone people (where calculated fields don’t do the trick because some accounts don’t have an actual assigned sender).

While this is only a workaround, in the meantime: 

Could you store your URLs into an object instead so that you’d pull those in your query from the object, still able to use the case statement to decide which URL someone gets (if that’s the level of personalization required on the URL front) but when there’s a change in URL, you wouldn’t have to modify the query?

And it wouldn’t matter when people join, because you’d pull the right URL at the time of them joining without having to modify your query (or your data design) and just having one UI to update your URLs?

Since we’re talking queries here, I think that’d do the trick. If they need to change when people are mid-journey, I would anyway use a calculated field to determine what the URL is at that point in time, so the object then makes sense too. 

Despite how much you try to test queries, run them in DDs before setting a program live, there is no substitute for real world data.  It’s not uncommon for changes to be required after the fact, either by the admin or from the original requestor of the program.  Sure, I could have the query source as a DD, but then does that not defeat the purpose of having a QB inside JO, and it means theres another dataspace to contend with, and the DD needs to be scheduled such that it runs before the JO schedule.

Please give us the ability to pause programs, edit the query and set active again.  Thanks.

Edit to the above post:

I remember now that even if I use a Data Design dataspace as the query source, there are still limitations where if changes are required to an active program, an admin would still need to clone the program in order to deploy the changes If you need to add a field for a token, or change a field name in the dataspace, the program doesn’t pick up the changes.  I noticed this back in Feb/March when there were larger issues with JO usability, and I don’t believe this issue is resolved in product.

The ask still stands; please give us the ability to pause programs, edit the query and set active again - regardless of the data source! Thanks.

Feature. Parity. PLEASE.

Just piping in again with a recent use case. I’m ONLY using the traditional JO builder for my programs at the moment.

The recent enhancement requests were the following:

• We used to exclude accounts where CSM was null. Now, we want to include them and have the Sender Email be one that we set as custom via a case statement. So I needed to edit all of our existing program queries to 1) add a transform task 2) create the case expression & new string fields and 3) update the fetch filter to now include where CSM is null.
  • I was able to do this easily without needing to create new programs that would mess up our metrics
• We introduced a Preferred Language field and additional language email template versions for our programs. I needed to 1) add the Preferred Language field to the fetch 2) map the new Preferred Language field in the program and 3) update the templates with the new version filters
  • I was able to do this easily without needing to create new programs that would mess up our metrics

HAD WE USED THE NEW DYNAMIC JO BUILDER for these programs (4 total), I would have needed to create four new programs. That means four new programs that I then need to also add in to our custom JO reporting & dashboards, and four new programs that create an even more disjointed program analytics experience, making it more difficult to tell the success stories of our digital programs.

Needless to say I was thankful I didn’t use dynamic programs. Unless this functionality is added, we will continue to not use dynamic programs.

I wish I could say the same – I’ve got one dynamic JO running currently (and it’s only internal-facing) – and it has already caused massive heartburn with our need for case statements to fix null emails.

Thankfully we’re not too concerned with the long-term metrics on this program, since we’re about a week away from releasing version 2 (and stopping the existing one), but it’ll be a pain if every time we need to update the program, we need to stop the old program, clone it, and start the new one – with a modified query to ignore recipients of the previous version. Because these are internal users, we can’t just exclude based on AO email data, and instead have to adjust our entry criteria each time we clone and start fresh.

In the new version, if your participant list is based on a query, that query can’t be edited once it’s active. It can’t even be edited if you pause the journey.

I have been told the following by a Gainsight CSM, which gives cryptic hope this will change. 

Unfortunately, audience updates are currently restricted. This functionality is scheduled to be included in the next feature update in Q3 ’24, which will support full program edits.

That said, I want to see this change and know how “full program edits” gets defined before I get too excited.

THIS! 

Hoo boy… back on this thread again today.

TIL (from support):

There is a concept called "Ghosting Fields" which has been introduced in Dynamic Programs

In short, it looks like if your query contains 12 fields, you map 5 in your program and publish it, JO drops the other 7 fields (it “ghosts” the 7 fields not used), and those 7 fields can’t be mapped once the program is published.

Searching the support articles and community for “ghosted”, “ghosting” and “ghost” returns 0 results, and the Admin Guide for redesigned JO (Audience Section) has no mention to this. Perhaps I should ask Bruce Willis to take a look.

In this (living nightmare ) situation where JO where edits are limited once published, it’s been a (spooktacular ) oversight from the docs team to omit the concept of “ghosting fields” from the product/support documentation. Enough to make you Scream? A fix in Q3 you say? Hopefully before Halloween …

I’ll show myself the door.

I actually ran into yet another situation where I’m REALLY glad we haven’t embraced new dynamic JO.

Just yesterday, we determined we need to add a new field to ALL of our recurring advanced JOs referencing a particular object in the query source(s).

In the “old” advanced JO, this is no problem (other than having to go into each query and add the field one by one). 

However, if all of those programs were in the new dynamic JO… big problem. I’d have to stop each and every affected program, clone it, add the field, exclude prior participants, and re-launch. 

Ooof… thanks for sharing that. Not the first time we learn something when submitting a ticket for an issue that ends up being “intended behaviour not called out in the documentation”... Adding that nugget to my mental vault for the time being 
FYI ​​​@corey.henningsen @Molly.McQ 

PS: Chapeau to The Sixth Sense’s reference 
 

Oh. Oh no. Add this to the reasons I haven’t started migrating any of our existing programs yet.

Not only do we have to stop and republish if we need to change the query. Now we need to republish if we decide we want to add an included field?

But wait… is that “mapped to a token?” Since “custom field mapping” is no longer a thing, I’m curious. 

@dayn.johnson  Let’s say your query contains field “ABC” that you did not map prior to publishing.  After publishing, you change your mind and want to change a token from being mapped to field “XYZ” to field “ABC”. As I understand you can’t, because “ABC” isn’t a mapped field upon the program being published, it becomes a “Ghosted Field” at the point of publication.  “Ghosted Fields”, I imagine, are the delta between your last dataset in the query and the “fields used” section of the audience.

Thank you for the clarification! And this as we’re looking to scale our digital-led CS… 

It’s extremely frustrating not having this feature available within the new JO program designs. It makes using new features like this very difficult. We need feature parity!