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? 🤔