I will also echo the need for deleting the system object from the MDA when the dynamic journey program has been deleted. Over time, retaining these with no ability to delete will make it very cumbersome to navigate the MDA in Data Management.  There really should be no need to maintain these tables once the program has been deleted.

Just revisiting this 4 months later… and the MDA is becoming VERY difficult to search and use. Programs need to be tested quite a lot, and the programs are only temporary then deleted. But the system tables created persist with zero records.

What is the long term plan for this Gainsight team?  We have 50+ test system tables since we started with the new Dynamic Programs 4 months ago. This will be hundreds within a year. 

Adding to this, we have some objects that were created based on the need at that time however, the object name is causing confusion for people that have access to Journey Orchestrator and can’t differentiate between the objects that they should be using.

@ssamarth Could we get some more info around this?

We only have one active dynamic JO right now, but I’ve created and activated a significant number of dynamic JO tests prior to the current version, and this has me a bit concerned about what the data is going to look like. @kstim, have you noticed any of this bloat in data management?

@dayn.johnson I have not! Definitely would be nice to delete the object if the subsequent JO program is deleted.

​@mgamache  ​@jrich ​@Veronica.Moore - Thank you for sharing this. Could you please clarify which objects you are referring to?

​@vmallya If this is helpful (​@kstim for awareness)… we have one Dynamic JO currently running.

When I searched for its name in Data Management (below) I got 11 different objects (and since we now have another name for the program following clone and relaunch), there are more, they just don’t all show up for the same search.

Digging into them, it looks like they’re the participant lists -- and unfortunately, it looks like each email template in the program has a unique object created that stores the participant data for each recipient of that email.

While this ( having participant data) is a good thing, having it bloat up our data management is not.

This looks like it could get really messy, really quickly.

​@alizee, as an early dynamic JO adopter, have you noticed any issues like this? 

​@dayn.johnson I do not have one object per email step although some objects do look like they contain a step ID, but I have one object per program but older programs that I built over a year ago do not have an object in the database… so it doesn’t seem like it’s all programs either (I have objects for QUERY and DATA DESIGNER based programs, but not all of them). 

Truthfully, having one object per program, if we were able to come up with a nice visualization might be good to show our team what’s in the pipe (subject to a good visualization option). 

Thank you ​@alizee!

I could definitely see the merit for having one object per program. And it’s reassuring to know that the participant data lives somewhere OUTSIDE of the JO, in case the JO is deleted and we need to access the information later.

This seems like (yet another) place where having tags (that we could use in filtering reports and dashboards) would be hugely helpful. Ex: JO, DD, Rule…

It’d certainly make filtering Data Management easier if we were able to sift through those objects a bit more easily.

They should certainly be their own category of objects, not “system objects”. 

THIS. This right here. 

Feels like the same should be true for DDs, etc.

Or have a properly documented “object source” field so we can differentiate between JOs, DDs and Surveys (although those have a suffix appended). 

thank you ​@alizee ​@dayn.johnson. This was created to provide a separate placeholder for the program and participant custom field data, outside of the AO Participants object.

As an immediate measure, please submit a support ticket with the list of objects you want to delete, and we will handle the deletion for you. ​ ​@mgamache ​@jrich 

For a long-term solution, I am discussing with the team ways to better classify these objects and simplify the structure to reduce clutter. We are also considering implementing a feature to delete the objects when the associated program is deleted.

​@vmallya Thank you for the clarification! This makes sense, and it’s fantastic to be able to have that data accessible. Like ​@alizee suggested below, if these had a clean object source classification, I think having these extra fields does more help than harm. It’d massively simplify reporting and dashboard creation to be able to pull participant data from these individual objects without having to track down the specific AO program ID to filter on.

As long as the dependencies were clear as far as deleting active JOs that were using these objects, that might also be a good way to prevent the accidental deletion of important, ongoing programs.