Dynamic JO needs additional data types if we are not allowed to do Custom Field Mapping.

Thank you to @vmallya for the insight shared in the community post about the recent patch! Sharing that response here for visibility for everyone else in the community following this idea, with my response below. 😎

Explanation

The issue with Events and CSV is that we don't have a data type reference, so all fields are treated as String when synced. Therefore, providing the option to change made sense in this context. 

For other sources like Segments, Query, and DD, the data type is defined. However, the challenge is that case statements in DD and Query do not currently support the output type of Email. We are working on extending support for email in case statements from DD to address this in one of the upcoming patch releases. I hope this will resolve the issue mentioned in the linked thread.

My response:

The lack of a data type reference being an issue makes sense since custom field mapping is not currently a part of the new dynamic JO.

From my perspective, the ideal situation would be to have the ability to change the data type in the audience configuration screen for all source types. The bulk of our JO programs are built using a query source (most using a similar object and merging different data depending on the target audience).

Being able to add a case expression transformation within the JO query (not within a referenced DD) is part of why we continue to rely on the old advanced JO. It’s a quick, easy, and reliable method of ensuring that the case statement string is able to be used in the email fields.

I’ll stay tuned to the roadmap to hear more about these upcoming patch releases, and look forward to hearing more about it!

This is an issue for us as well.  We were used to deriving a send from email address in the old programs that can be used in emails.  The new advanced programs does not support this previous behavior and causing us challenges.  We have found a hack to do this via calculated rules, but is less than ideal.  It would be very useful if you can create parity between the old designer and the new one by supporting this need.  

The original post by @dayn.johnson  has the exact same use case we ran into. Our “wait is this really missing from Dynamic Programs?” moment came when we needed to override email addresses based on a case statement. 

Before we could map things like sender email, sender name, etc in the standard or custom field mapping. Sender, for example, might be different depending on the participant. This logic needs to be calculated in the query at times.

In the new dynamic programs we have no ability to map standard or custom fields (outside of recipient email). And on top of that, not having the ability to change the type of the fields leaves us doing risky workarounds. Please try to provide this core feature to dynamic programs ASAP. 

This ☝ is so closely related to this idea it’s not even funny. I can’t count the number of times we’ve needed to add a case statement to an active program (which is not possible in dynamic JOs). Please, I’d love to be able to start using dynamic JO, but until we have this #productparity with the “old” advanced JO, it’s just not practical.

How would customers with existing JO programs eventually migrate to dynamic JO programs without this?

For us, at this point? We wouldn’t.

Part is due to not having these additional data types available for ad-hoc (in-query) transformations. The other is the lack of multiple queries -- the execution action schedule doesn’t help when we don’t have user-level (or company level) time zones. We’d need to start building regional variations of each program type, with a different query for each (and additional case expressions). So one program would have to be migrated as three (or more).

THIS is one of the top reasons I’m not using new JO. This, and the inability to make changes to queries in active JOs.

Jumping back in on this post -- @vmallya, any updates on where this might be on the roadmap?

However, the challenge is that case statements in DD and Query do not currently support the output type of Email. We are working on extending support for email in case statements from DD to address this in one of the upcoming patch releases. I hope this will resolve the issue mentioned in the linked thread.

@alizee posted an absolutely brilliant solution for creating a fallback sender if the relationship sender is null. 

For those cases that are outliers, I think I may have solved for the issue of email data types not working in dynamic JO, but it’s definitely not as easy as custom field mapping. And this is yet another reason I’ll plug @matthew_lind’s answer in the Admin Training Corner series (from awhile ago) about clearly labeling your steps: 

Question for everyone else:

Curious to hear what everyone else is doing (if you’re using dynamic JO), or if you’re staying with advanced JO until we’re able to actually map custom fields for DDs and query sources.

My solution:

I created a Case Expression Data Design (DD) template that could be pulled into other DDs or queries.

My solution is below, but I’m curious to hear what everyone else is doing.

The union is key. See the hover text in the “information” tooltip for the Master Field column. 

Unified Fields will inherit the properties of Master Fields such as data type, decimal points…

👆 this means that mapping the Case Expression output (string data type) from Transform 1 to the original email field from the Company Object will force the Case Expression output to acquire the email data type. This allows that Case Expression email address output to be mapped in an email field in the dynamic JO.

The output from this case expression can then be merged into a previously created DD or query as needed (like so).

Hi ​@vmallya, checking back in to see if there might be any update on whether dynamic JO’s roadmap over the next few months includes custom field mapping. Between the limit of 10 calculated fields, the inability to edit a query in an active dynamic program, and the difficulty required to set up case expressions in data designs when we’re transforming a custom email string back to an email data type, there are a lot of obstacles to our adoption of dynamic JO for any external-facing programs.

Happy Holidays!

This is a big question that would put a few minds at ease if we knew what was coming.

There has been fairly consistent feedback over many months - especially around field mapping, any update here ​@vmallya ?