Currently, when a participant list is generated and all fields are mapped, they are “locked” with those values. This makes it prohibitive to use Journeys for communications over time. Here are some examples of issues:
- CSM changes after the Journey starts
- CTA is assigned to the CSM when the participant list was created instead of the current CSM
- Emails are sent from a previous CSM, and the client may even respond to a previous CSM
- Client’s email address changes
- Email is sent to an old email, potentially exposing company information to a non-customer
- Other fields become outdated
- Tokenized fields in CTAs and email templates surface inaccurate information the day the communication is created
The participant List is mapped to fields with real-time updates and the file should be upserted at minimum before each time an action within the program is occurring for those participants.
The first use case can be solved by using calculated fields@angela_domenichelli
The others that you posted are definitely valid suggestions.
The first use case can be solved by using calculated fields@angela_domenichelli
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.
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:
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?
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.
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?