Acknowledged

Dynamic Program Sender token

  • 1 October 2020
  • 8 replies
  • 83 views

Userlevel 7
Badge +1

I have a customer that has a use case to need a dynamic field / option fro the “sender address”.

They have a number of accounts that don’t have data for the field they are using as the sender and they would like to use one program and have that field change to a default value to still send.

 

I think this would be huge and a major asset to JO.

 

 


8 replies

Userlevel 7
Badge +1

Could they use a Transform task and a Case Expression to create a new field called Sender Email that would either 1) be populated with the value from the record or 2) default to a default address and then map Sender Email to the standard field for Sender Email Address? I’ve done that when there were two different possible senders based on the account type.

Userlevel 7
Badge +1

Could they use a Transform task and a Case Expression to create a new field called Sender Email that would either 1) be populated with the value from the record or 2) default to a default address and then map Sender Email to the standard field for Sender Email Address? I’ve done that when there were two different possible senders based on the account type.

The issue with that solution is that the system doesn’t accept string fields as an email token and since case expressions only can yield string, number, or boolean, it doesn’t work :( 

Userlevel 7
Badge +1

The issue with that solution is that the system doesn’t accept string fields as an email token and since case expressions only can yield string, number, or boolean, it doesn’t work :( 

Right -- I think I used branching logic on a Conditional Wait with two different Email fields so that only works on email steps after the first.

Could you then move the case expression to a Rule and have it load to a custom email field?

Userlevel 6
Badge +1

+1, just ran into this issue. We can use calculated fields for Sender Name but not Sender Email which makes this less useful.

Userlevel 7

Acknowledged. We will look into opening string fields for email tokens.

Userlevel 2

@nitisha_rathi - Is this going to make it in to the JO redesign this year? This would be incredibly helpful to have dynamic from addresses and names. Like the logic for variants. EG, of what we would want to do with it, if the account has a CSM, it would come from the CSM, if not, from the Account Exec.

Userlevel 4

I second this - I was trying to send personalized emails from our CSMs (we do not have them listed on accounts in SFDC due to pool model) and thought I could just use the variants for the emails that were personalized to the CSM name, and then hard code the sender name and email to that person...but those two things cannot be different on each of the variants.  Seems like each variant should be able to do that.  Don’t want to have to create a formula field in the data for each variant.  Each version should be able to be completely independent.

Userlevel 7
Badge +4

Yes please!  We have situations where depending on the region, we would want the email to come from someone different.  I wound up building an MDA object to store the assignments, but that’s a lot of upkeep.

Reply