Participant list should be dynamic

@angela_domenichelli Thank you for your feedback. Redirecting this to the product team.

The first use case can be solved by using calculated fields @angela_domenichelli 

• How to use Calculated Fields in Journey Orchestrator Programs

The others that you posted are definitely valid suggestions.

spencer_engel wrote:

The first use case can be solved by using calculated fields @angela_domenichelli 

• How to use Calculated Fields in Journey Orchestrator Programs

 

The others that you posted are definitely valid suggestions.

Thank you for this!  I will look into this as we develop more Programs.  I’m guess we cannot change the mapping for an existing program?  This was not offered as a solution on ticket 155811, maybe because it is an existing program.

I originally posted about this a few years ago - I would love for fields to be dynamic in replacement of calculated fields, which aren’t intuitive to set up. Especially so if it’s a field that contains multiple values - which I’ve had a few of that required case expression fields for each value I was looking for in order for the calculated field to work. 

Or at a minimum, identify something that is dynamic and should be real time and something that is calculated where you’re specifically looking for a value change.

 @anirbandutta tagging you in some posts with 1 or more vote and no status based on this blog: 

• Gainsight Community Product Ideation Guide Blog

This would be so useful and save a lot of time. I frequently run into an issue with some of our programs (that aren’t even long of a journey) where the CSM changes on the account, and the CTA gets assigned to the old CSM. Regardless of length of program, accounts change hands because of CSM attrition or territory reassignments or what-have-you. Instead of making me create a calculated field for all of my programs that will assign CTAs to ensure it’s being assigned to the current CSM, dynamic updates to the participant list would save a lot of time and complexity.

Adding more color here -- while some folks might think that Calculated Fields can solve for this issue, I have learned that it cannot for CTAs. My comment above ^ I stated I would pursue a calculated field for the CTA Owner, but I have recently learned that this is not supported, and that I must use a Standard Field Mapping for the CTA Owner and cannot use a calculated field.

Here are similar community posts referencing the need for dynamic program fields:

• 

  • Programs - Designate participant fields to be updated if changed e.g. CSM New Idea
  • 17 Votes
• 

  • Are Programs participant field values static?

   

This is a major issue for a current use case at athenahealth - particularly that we are sending emails to the client from a CSM that no longer works for our company.  When we get a 2 week notice and a Program runs with the same list for 1 month, it is an issue.  Can I get an update on the expected implementation?

Just re-read Specer’s first response to use Calculated fields.  Working on that now.  We also need to have an API to re-assign the CTA to the correct CSM.  This should all be native.

Calculated fields are not recognized as valid email addresses in Preview - will the Program run with a calculated field in the from and reply-to email fields?  IOs this just a limitation with Preview?