Allow reporting on custom mapped fields in Journey Orchestrator

@spencer_engel Thanks for bringing this up! We have added this to our near term road-map items. I will update you here once we consider it for release. 

It would be great if custom fields were reportable from AO Emails, as well.

Yes, I came to know that we are not storing the Custome field Mapping fields in AO Participant object as we are offering to add 50 custom fields in the Custome Field Mapping section in JO.

+1, recently came across while working with Support on a program we are trying to set up. This would be super helpful to have again. 

Another common use case that is much more difficult now without being able to report on custom mapped fields: A/B testing. I created a program where I used a Case Expression to split my participants so that half would get an “A” version and half would get a “B” version.

This all worked great, but...reporting on it is a huge pain now. I should just be able to use the AO Participants object and filter on my custom mapped field that designated the participant either A or B. Instead, I have to download the participants file as a CSV, upload it to a custom MDA object, and then merge it with the AO Participants object - all just to get this one custom attribute into my dataset. This is a LOT of extra work.

Reporting on custom fields will be available in Feb

Super cool Thanks.

This would be super helpful…….

Thank you all. Critically important for us. we use very few custom fields on our programs but they have essential reporting elements. e.g. which test group A/B or which cohort are the participants a part of. 

Hello Everyone!

Happy to announce that your request has been considered and included as part of the v6.22 release (SFDC / NXT). Journey Orchestrator custom fields are now available to generate reports from Report Builder as well as used as a source in Query Builder under the AO Participants Custom Fields object name. 

This feature is implemented in both SFDC & NXT versions.

Thanks for posting!

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.