Reconfigure Query in Active JO (new version)

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. 😱