Skip to main content

I’m trying to adopt the new version of Journey Orchestrator, but keep finding areas where it’s not in parity with the old version!

 

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. The only solution I see is to clone the journey, make updates in the new, and activate changes in a new program. TL;DR this is a hassle, and time consuming! This is challenging because you have to then manage different versions, potential exclusion list for the new JO to not pull in participants from an old version, you have to monitor the old to make sure everyone has complete before stopping, you have to create reports to get analytics of all versions, etc.

 

Would love to see the flexibility that the old version had, where you can adjust your queries on active JO’s. 

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 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! 


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


New IdeaDevelopment

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.


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.

 

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


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


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.

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

 

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!


It’s definitely not ideal to have to Pause/Stop a program simply to add a filter for participants.

 

☝️ 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.


Feature. Parity. PLEASE.

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. 


Feature. Parity. PLEASE.

What’s funny about this lack of parity is old JO didn’t used to be editable, either.

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.