Reconfigure Query in Active JO (new version)

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.