Hi,





Yes Kelly, the participant fields are static in programs ie. once the participant is added into the AO, we do not modify the value based on date from subsequent syncs **yet**. 





We are looking at the ability to update the fields based on source sync as part of the roadmap. I will update here once we have the timeline for this.





Thanks


Abhishek S

---

Excellent question.  The management of the data in a process instance is fundamental.  In an instance of a Program, the participant values are fixed at the beginning.  This is intentional since we need to capture and be able to refer to the state of the world that led to this instance being created.  Of course, there are also plenty of reasons to want live data.  For example, one of the participant fields could be a utilization metric.  If a customer has low usage, we need to recognize that, remember it and be able to refer to it.  If the usage goes up over the course of the process we need to be able to observe that and adjust the execution of the process or even end it.  This is what we enable with our Calculated Field construct in Journey Orchestrator Programs.  Indeed, a common pattern would be go compare the current utilization with the initial utilization, so both are needed. 





Currently, we can only use the dynamically accessed data for decisions in the process execution (that is, in Conditional Wait steps).  We can't (yet!) use these dynamically accessed values in things like email tokens or -- crucially -- in reports about the Program instance.  E.g. we would really like to see a trend of the utilization metric over the course of the instance.  These further uses of dynamic values are coming. 





Having said all of this, the specific use case you mentioned of finding an error in a more or less static field, like First Name, is a bit different.  This isn't dynamic data as we normally think about it.  I could see a potential option for changing this data after the process instance starts but I worry that it could be confusing.  For example, if a value used in a Conditional Wait step is changed later, it could be very hard to go back and make sense of what actually happened.   We will think about this further but my initial thought is that starting as a new instance may make the most sense, perhaps with the ability to skip over some portion of the Program in the second instance.  

---

[i]"starting as a new instance may make the most sense, perhaps with the ability to skip over some portion of the Program in the second instance"





Is this suggesting to have a second program that has a conditional step that skips email 1 if they've already received it? And what would be the process for getting anyone that had to be dropped from program A to enter program B? 





That doesn't seem very scaleable, especially with programs with much more advanced and lengthy journeys. 





I see your point about wanting to capture the static entry points but I think anything that is tokenized in an email should be truly dynamic. 

---

Agree!

---

Sorry I wasn't clear.   By 'skip' I was referring to future functionality where we enable a more direct 'skip to XYZ' capability.  I agree that today it would be a fairly involved effort to set it up to check whether someone had already received an email during a second run.  You can, of course, knock a participant out of the Program and add them back. 

---

There’s a related feature request/idea here that some of you may want to vote for.

The request is to allow some way to update participant fields of an active program. For example, if the CSM changes and the program is sending emails out from the CSM, we would need that to change to the new CSM.

---