Allow reporting on custom mapped fields in Journey Orchestrator

I realized this is marked as solved, but I have to say, looking into this that (to me at least) having this in an entirely separate object is a huge pain. I was really hoping I would be able to pull up my flattened survey, go down to AO participants where all the other mapped fields are and select my likely generically named custom fields.

Looking at this object, I have no clue survey to survey what was String 13 or Number 6.

I understand that I will likely need to use Data Designer to do this, but since that was the workaround before, how is this an improvement? I realize that sounds rhetorically condescending, but I mean that as a genuine question, as I haven’t had an “aha” moment yet using this new object to see why it’s better as it still forces me to use DD. @rakesh_lingala or @sai_ram could you give any insight? Does it just streamline the process of reporting on any survey detail *except* question responses and that is the problem it solves? Is there something I’m missing on how to use it with my survey responses?

Also, should this be a separate discussion thread?

I’m also curious if there is any further documentation I’m missing on how to routinely determine which custom field was mapped to String 1, String 2 or Number 5, etc in this object, or if it is just guessing and checking.

Thanks!

@sai_ram  or @rakesh_lingala any feedback on this? Genuinely interested and wondering if there is better documentation I’m not seeing as well.

@bradley I am working on this and will get back to you on this. Thanks

@bradley  Based on your use case you still should be able create a lookup to “AO participant” object using the new custom object and get the same functionality you explained.

Hello @varun_menon thank you for the reply. Can you clarify what you mean? When looking in Data Management the AO Custom Fields already has a lookup to Participant, but when I pull up the flattened survey object I don’t see any reference to the new object in there. Do you mean I should use data designer and merge them, or what? Thanks!

@bradley Sorry I missed the part that you are coming from flattened survey object. 

No if you are coming from survey flattened object then there is no way to go to “AO Participant Custom Fields” from there.

You have to go with the route of Data Designer for this and merge records based on participant id.

@varun_menon ok, that makes sense. That does bring me back to my original question though, paraphrasing..”I understand that I will likely need to use Data Designer to do this, but since that was the workaround before, how is this an improvement? …. Does it just streamline the process of reporting on any survey detail *except* question responses and that is the problem it solves? Is there something I’m missing on how to use it with my survey responses?

Earlier the object was not visible hence users were not able to use any data from the said object,. They were neither able to report on them neither were able to use it in other places.

Now with the visibility of the said object customer can use the columns and fields using participant id or program id to use any custom entries in emails and other places as per their needs.

Gotcha, that makes more sense. I think I was conflating some of the participant fields with what shows in the new AO object. And not having tried to report on the custom ones before wasn’t sure exactly what it was solving and how :)

I’m curious why the “Context Attribute Boolean 1,” Context Attribute String 1,” etc. still even exists on the AO Participant object if this new AO Participants Custom Fields object is now the recommended solution. Also, those “context” fields are not documented in the object glossary and appear to be blank across all of our programs.