This is definitely needed, especially after a Conditional Wait. I can use a calculated field in the conditional wait to determine the path, so I should be able to use the Calculated Field in a field to determine which email variant is used

I’m surprised I haven’t hit this issue yet in our JO creations because I completely agree that this functionality should be available. In fact I would have assumed it would be available as you can use calculated fields in just about every other aspect of a JO program.

This would definitely be beneficial functionality to improve JO.

100%. Really surprised I haven’t hit this issue yet, come to think of it.

Maybe dynamic content will solve this issue, whenever it gets here?

Thought I’d upvoted this before - perhaps there is another idea out there that’s similar?

Consider an email campaign with email steps across several months. The customer/recipient can change their language (process isn’t relevant for this). So let’s say it was defaulted to English when the participant entered the journey, however during a delay step, the customer updates their preferred language to Spanish. Person MDA record reflects their current preferred language, however as calculated fields can’t be used to determine email version sent, the campaign continues to send emails in English for the remaining duration.

This isn’t the end of the world, however let’s take a look at customer perception. We’re saying to the customer we support your language, however we’re continuing to send in English. It’s really not a great customer experience.

I really like email versioning as a concept, but there is a real requirement for the product team to revisit how it’s deployed across Gainsight and bring in improvements; calculated fields as filters is one area, support in playbooks/CTAs is another as I outlined in these posts:

https://communities.gainsight.com/ideas/variant-email-templates-in-email-assist-3089/index3.html?postid=44444#post44444

Checking back in on this -- ​@ssamarth, any chance this’d be on a roadmap somewhere? This would be massively useful as we’re scaling our programs, and it’s definitely a letdown when we forget we can’t filter using calculated fields and get a program built to rely on them, only to have to change it.

This should probably be merged with this idea and its votes from 5 years ago
 

Hi ​@revathimenon Can we merge this idea with the one mentioned by ​@kelly ?

Also ​@vmallya (hi ) - pretty please? That would be quite game changing… Changing the version of an email dynamically based on an opportunity close date… to be seasonal (for example). Instead of branching branching branching. 

100% -- Dynamic JO branching logic with separate email templates is unfortunately the only way to do this at present time, which significantly increases the number of templates required per program, as well as the possibility of human error by having to map each template and version configuration.