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

We sincerely appreciate your feedback on this thread and understand the ongoing sentiment. Our goal with the new version was to simplify processes in JO, ensuring that once you add a source, you wouldn’t have to do any additional work to utilize that data in the programs. We will be improving this further in the data prep process as we get the fundamentals in place.

​@dayn.johnson please know that we are actively working on improving the quality of the existing features and starting in Q1, we will begin introducing query edits to live programs and continue implementing additional enhancements. We are also in the process of adding email data types to the case statements that would remove the need of creating custom fields in JO. 

​@rrobinson regarding the migration, the underlying assumption is that all mapping data is linked to a source object/field, and those fields will be carried over to the new version along with the mapping metadata, including the data type. This will ensure that the data from the old versions is retained as is after the migration. However, we will thoroughly verify this during the migration solution scheduled for the end of this year.

Apologies for the late reply.

​@vmallya - for Q1 2025 - will editing Live Dynamic Programs be limited to the Query - or can we edit further down the path - like evaluations and calculated fields?  We are developing multi-step digital programs using Dynamic, and one of our big concerns is the inability to apply lessons learned without Cloning and Changing which also means actively managing participants in multiple versions of JO Programs.  

Both of your statements to ​@dayn.johnson here are very exciting - email types are another challenge for us using Dynamic programs - where very few fields are showing up as selectable as Email addresses with no way to customize the field type in the current release.

Thanks to you and your team for pressing these much needed features!

Updating with the full solution, since this is still an issue, 7 months later. Why make us do our mapping within the Data Designer or query, and remove a perfectly good and much loved feature that’s still a big part of our reason for sticking with the tried and true advanced JO?

Quick overview (screenshots below):

So this is the setup I've got (saved as a Data Designer TEMPLATE) for easier use in the future.

• Transform with the case expressions (string text for custom email).
• Union to force the string text to inherit the email data type from the master field, shows other fields beside the unified fields.
• Not sure why the second transform was necessary, but it didn't work without it.

Took a LOT of experimentation to get this to work.

This is the key:

Unified fields inherit the properties of the master field (including the DATA TYPE), so in effect you're mapping the fields within the data designer itself. Not in the audience setup (which is possible with events and CSV source types). Labeling and descriptions are your friend here.

Updating with the full solution, since this is still an issue, 7 months later. Why make us do our mapping within the Data Designer or query, and remove a perfectly good and much loved feature that’s still a big part of our reason for sticking with the tried and true advanced JO?

Quick overview (screenshots below):

So this is the setup I've got (saved as a Data Designer TEMPLATE) for easier use in the future.

• Transform with the case expressions (string text for custom email).
• Union to force the string text to inherit the email data type from the master field, shows other fields beside the unified fields.
• Not sure why the second transform was necessary, but it didn't work without it.

Took a LOT of experimentation to get this to work.

This is the key:

Unified fields inherit the properties of the master field (including the DATA TYPE), so in effect you're mapping the fields within the data designer itself. Not in the audience setup (which is possible with events and CSV source types). Labeling and descriptions are your friend here.

Crazy workaround! What a pity that we have do to all that to make it work, but it’s great to know that there is a way!! Thanks for sharing ​@dayn.johnson !

Thanks Dayn! This is perfect.

But like you’ve already said.. this should be such an headache for an admin to accomplish especially since the product already had functionality to change the datastypes :( 

​@dayn.johnson Thanks for sharing; looks like I might just use the old programs for this kind of use case for now though...

​@vmallya checking in approximately 5 months later – any update on whether we might be able to get custom field mapping for data designs and queries in dynamic JO?

While Advanced JO is still an option (for the time being) for those of us on older instances, we all know there’ll be a day when it won’t. Between not being able to map strings to email fields, the fact that we can’t add multiple queries, the inability to preview participant calculated fields… 

While it looks like some of these ideas are in discovery or development, it makes it very difficult to choose to launch a new program in Dynamic JO when Advanced JO makes it so much easier.

There’s so many good parts in Dynamic JO (Evaluate Criteria Before Action, Multiple Branches, Action Step Execution, etc.) — but if we can’t make it work without lengthy workarounds, adoption is hard.

​@dayn.johnson and everyone here - we will be releasing the following in July, and you’ll receive the details soon. I’ll also update the other threads shortly

Thank you ​@vmallya! These screen recordings look fantastic. 😀

Thanks ​@vmallya