SOLVED

Sender Email not showing as option under From Email

In my DD I have Sender Email, which is created through a case expression. It shows as available in other fields, but doesn’t show up as an option in the “From Email” field. 

Only Recipient Email is showing as an option under From Email: 

You can see that Sender Email is available as a field under From Name, so it is in the data:
 

Have I done something wrong here? Does it need to have a specific name to show up as an option under From Email?

Best answer by eriklangston

@vmallya @HMM Not sure if this is solved but we currently have a similar scenario where we needed to send from a different user based on account criteria.  I was able to rename the email field in a transform to “Sender Email” and then use the transform filters as the “case criteria.  Create a transform for each “case”.  Then did a union and made sure the email fields were labeled the same.  That allowed me to use different user emails as a sender email in the JO

Transform for IC:

Transform for CSM:

Union:

Email in JO:

Hi @HMM 

What’s the data type of that field? Dynamic JO doesn’t have the naming issue like Simple Programs. I am using a field called “CSx Email” that I add to the From Email field and it works fine.

My best guess is your case statement field is not an email data type (it’s a string) and that is why it’s not supported here.

Try with a field of email data type.

Not that it shouldn’t be fixed though, I also use case statements to generate fallback senders when there’s no CSx. Deffo a use case that needs to be supported.

Thanks @alizee ! I thought that might be the issue as well, but it seems to only allow me to choose String, Boolean and Number. So not sure where to go from here. I haven’t worked with DD in the past. Am I missing something on how to make this an email data type?

Hi @HMM 

Yep, the case statement doesn’t support email as a data type nor others that would be useful like URL... I think that’s because we no longer have to map our fallback email to the “recipient email address” which possibly was acting as a “converter” to email data type.

@vmallya This needs to be brought back. But I would personally think we should have an “Email” case statement data type. This would all things considered be smarter to avoid the accidental mapping of string values (which are not email) into that field. But I understand that’s got nothing to do with JO itself. 

HMM

Thanks for the help @alizee
Unfortunately, we can’t use the new experience for most of our programs without the ability to create the sender email through a transform.

In the old experience the sender email is transformed as a string and we’ve never had issues with this sending. If this were to GA without the ability to use a transform for the sender we would be in trouble with our current setup @vmallya.

@HMM - we’ll look into this and work on a solution for GA. Thank you.ER

@vmallya @HMM Not sure if this is solved but we currently have a similar scenario where we needed to send from a different user based on account criteria.  I was able to rename the email field in a transform to “Sender Email” and then use the transform filters as the “case criteria.  Create a transform for each “case”.  Then did a union and made sure the email fields were labeled the same.  That allowed me to use different user emails as a sender email in the JO

Transform for IC:

Transform for CSM:

Union:

Email in JO:

Interesting @eriklangston ! Thanks for this info. I haven’t tried it with a union! Normally I do a Transform with a case expression where it’s basically “if level = tech touch then use Tech Touch email, else use CSM email”. And that output is named Sender Email. That hasn’t worked so far though. 

In this scenario, how does the JO know which email to use? I would like to try to replicate your approach!

Edit: Sorry, the transform filters part didn’t immediately click in my mind. I think I get it now. Trying it out!

It works! It was showing the new Sender Email option but wouldn’t let me select it. However, I tried it in a brand new program and it worked, so I will just need to delete and re-add the dataset on my existing program. Thanks again @eriklangston ! This was a big concern of mine :)

@HMM yep, glad it worked.  I treat each transform as a “case” statement.  So whatever criteria you would put in the case you use the filters for the transform.  Then you have a transform for each case. I had an issue with my program using it as the sender then i checked the Mandatory fields in the Program setting and it had defaulted the Sender Email to the Recipient setting. make sure to check this and its not set to your sender email field

Thanks for posting @dayn.johnson!

Hey @Snigdha Adiraju, following on from April’s meeting, I wanted to highlight this is a great example of not having parity between old + new a in feature migration and making utilization harder, not easier, in (some) admin use cases.

Thanks!

Adding my +10000 for this request. It is an extremely common use case to leverage case statements in order to yield a specific sender email for a participant. Some common examples below:

• If CSM is Null, use Email X. If CSM !=Null, use CSM Email
• If CSM is Null, use Account Executive Email. If CSM !=Null, use CSM Email
• If Geo if AMER, use Email X. If Geo is APAC/APJ, use Email Y
• If ARR is <$100k, use Email X. If ARR >$100k, use Email Y
• If Segment is Digital, use Renewal Specialist Email. If Segment is Mid-Market or Enterprise, use CSM Email.

The list goes on and on. It was so easy to accomplish this in old JO, and nearly every program I launched at my previous org needed to use this logic. If this isn’t possible in Dynamic JO, then it is unusable.

Huge blocker to use the new JO. We admins use cases like Sarah's examples above day in, day out.

Thanks @dayn.johnson for taking the time to submit this idea!

Love these examples, @sarahmiracle! Thanks for chiming in!

This! Thanks for posting @dayn.johnson and for the examples @sarahmiracle . I was on a call with support team yesterday for precisely this issue and had to go back to building a program in the old JO :( 

For my part, the workaround for the email topic is working just fine and is probably smarter than the old way of doing things (as far as I’m concerned so it doesn’t bother me anymore).  

With that said, case statement fields MUST be revamped not just in JO - in HRE / Query / DD (and all the UIs that use that engine). 

Suppose I should have named this post “Data Designer needs...” rather than “Dynamic JO needs...”

Whoops. 🤣

This new patch release ([NXT] V6.41.4) has me wondering. If all of these fields are now available for the event source type in dynamic JOs… why are they not available for queries and data designs? 🤔

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. 

• Gainsight Community Guide to Fallback Senders​

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: 

• Admin Training Corner Series - Rules Engine

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 ?

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!