Dynamic JO Sync Issue when using Query Builder Source

I had this same issue and submitted a support ticket late yesterday. No updates or additional details to share yet. 

We have been able to sync and issue does seem to be resolved. Yay! 

Hi, @ebell 

We are able to Sync all, but we still don’t see the data change reflected after adding a new filter criteria - still requires us to change the Uniqueness criteria to force the new data to display. Our bug report is still open. 

We re-opened the ticket as well because we were seeing something similar when we cloned other programs and this is the last response we received but we have not tested yet. 

“ ...it will not drop the previous participants that are brought in. You will either have to manually remove them and then re-sync or completely delete the source and rebuild it. Modifications to the query are only going to effect NEW participants being brought in, not existing ones that were already brought in from a previous sync.”

So I guess when cloning the system thinks the sync has already happened. But I still don’t understand why this would be the solution because in a new program you can edit and resync the query multiple times and it gives you a fresh participant list. (Unless I’m wrong, which worries me about other programs we have released.) 

We’re just having problems troubleshooting the result set/participant list at this point. If I add a new filter or change the criteria I want to be sure my FULL result set/participant list looks good and if it doesn’t I want to be able to see where in the multiple query steps something went wrong. Think changing from North America to Europe or adding a new filter for Market, after you sync, you see a mix of old and new. Whereas before in the old JO we had the option to Sync and Replace the Full participant list. In addition, we can no longer see the result set of each step in the query in the Execution history and export it unless Im just missing it. 

This is what I was told regarding this behavior, “This IS considered expected as making updates to the query and re-syncing will not remove participants that were already brought in unless you either delete the source as a whole or manually remove participants that were previously brought in.”

@dayn.johnson You’re more experience than me. Does this sound right to you? 

Hi @ebell, could you please clarify this for me?

What Dynamic JO sources are you saying are able to be modified within an active program?

We have exactly ONE dynamic JO running (internal), with a query source (screenshot), and to make ANY changes to the query, I am REQUIRED to clone and start a new program, and find some way of excluding the prior participants. (which is made more difficult since I can’t just exclude based on email addresses or whether they received the email previously).

EDIT: here’s the idea about editing active dynamic JO queries: 

I’ve begun rebuilding a higher-level source as a Data Design template (and Data Design) so I can bring that in and then apply the specific program filters in the audience menu, rather than in the query, but that’s also made more time consuming since you are unable to save existing query sources as a Data Design template.

I was following the big big issue (below) quite closely in the GGA community, but this sounds like a different issue, unless I’m misunderstanding.

Response to @AdriP ☝

For what it’s worth, while most of our current JOs (advanced) all run on multiple queries, I’m now thinking it might be in our best interest to develop a few higher-level audience DDs (all active users, new users, internal audience, etc.) and filter the DDs in the program, and then use a conditional evaluate step to time our different sends, rather than having individual queries within each program. That way if we need to make adjustments to our regularly recurring programs, we just update the DD or the audience filters in the active programs, rather than having to clone or make changes to every single active JO.

Hi everyone,
Just wanted to let you know that I’ve informed our team internally on this discussion & they are looking into it. 

This along with the inability to delete failed participants before publishing wreaks havoc on any attempt to have accurate data. Dynamic JO needs feature parity with old JO. 

This doesn’t even BEGIN to cover the fact that dynamic JO doesn’t allow us to use multiple queries. This is one of the main blockers we have to migrating multiple triggered JOs to the new dynamic model, even if we were able to edit a query once a dynamic JO is published. (spoiler -- we can’t)

As much as I’d love to start using dynamic JO for every new program, I have to practice EXTREME caution with what I build there -- especially if it’ll be client-facing.

Even now, advanced JO is my faithful friend, and dynamic JO is his quirky companion who’s learning his way. There’s a lot to love with dynamic JO (action execution schedule and multiple branching paths, more than three CCs, evaluate steps before the first action, etc.) -- but it just doesn’t feel ready for prime time.

I know it’ll get there -- and I can’t wait for that day to come. 😀

• New Dynamic JO Should Have Multiple Queries (just like older advanced JO) Discovery
• 23 Votes