Include Journey Orchestrator Dependencies in Data Management

Related products: None

We’re doing a little spring cleaning and I noticed that there is no dependency section for objects used in JO programs (unless I am mistaken?) This is a huge blind spot and can lead to email programs not working if data is inadvertently deleted before the program is rebuilt to use a different MDA object. 

I have also noticed this being a weak spot in JO migrations using Query Builder for the Participant Sources. I have had to rebuild Journeys too often...


@sai_ram @lila_meyer is this an improvement we might see in the NXT instance?


Hi Ana, there are some dependency warnings related to JO in data management. More info here. If this isn’t quite what you’re looking for, can you explain a bit more?


Hi @lila_meyer this is the Data Operations feature, but I am referring to MDA object dependencies, specifically for Custom objects. There is a section for Email Templates but not for the actual queries.

 


@sai_ram Have there been any updates to this functionality? Maybe I missed it in a recent release?


@sai_ram Have there been any updates to this functionality? Maybe I missed it in a recent release?

@ana_g sorry for the delay here, the discussions are still in progress. Happy New Year!!


@Cornelia and @anirbandutta I realize this is marked as ‘not planned’ but this is a really big blind spot in the product that also hasn’t been included in the new Data Management. Its absence is frankly a mystery to me - if I’m trying to determine if we can delete a field, repurpose it etc., if it doesn’t show up in the dependency checker I will STILL have to to check every single query just to make sure it isn’t in use. That doesn’t make any sense.

 

Can someone help me understand why this has not been, and apparently will not be, addressed?


Let me try to get some answers here @bradley 

 


Resurfacing -- just hitting this issue now. We have over 70 journey orchestrator programs, accounting for over 100 email templates. This makes our lives quite difficult when we have to assess impact of field changes!


Let me try to get some answers here @bradley 

 

@anirbandutta any news on this? Lack of JO dependency visibility is a huge blind spot. Not only does every query need to be checked, but each field in a transform step, each custom mapped field, each template token, each conditional wait, email template variation, etc. Even if you have one program that’s quite a bit to validate, and the time component only multiples from there as you have more than one program.


@PavanCh could you pl share the latest on this usecase?


Updated idea statusNot PlannedUnder Consideration

Happy to share that we are actively considering token dependencies management as part of the Journey orchestrator redesign project. The first build is expected to be beta ready H1, 23


Happy to share that we are actively considering token dependencies management as part of the Journey orchestrator redesign project. The first build is expected to be beta ready H1, 23

Great news! Will the fields used in the queries be a part of that as well? Being able to track query level dependencies just like we can with rules would be the biggest gain for admins.


@PavanCh @anirbandutta @GameChangerAdmin 

This was marked as ‘not planned’ up until a day ago. Today I discover this in dependencies:

 

So does this mean that this idea has been implemented? Or implemented for some objects? Or for queries but not for tokens???


@PavanCh 
Looks like its limited to MDA, can we also include Salesforce objects?
There is no way to know dependency fields for SFDC objects used in JO programs 
 

fyi, working with support on this (ticket  #205508); any interim solution would be appreciated.