Tokens/Wait Steps change in real time

[Jackie_Patterso]

Recently our team had an event scheduled for a particular date. The program was built as an event and tokens were used for time, date, location etc. Smart Campaigns were also created to send out confirmation emails, reminder emails etc. Unfortunately, the date of the event needed to be pushed back to a later date. All of the tokens and wait steps changed, however they were not applied to any of the leads/contacts in the wait step. I find this to be a major design flow that the tokens and wait steps do not change in real time. It is expected behavior that the tokens and wait steps originally set in a smart campaign will remain. My suggestion is for tokens and wait steps to always react to what is shown for circumstances such as event date changes etc.

[SanfordWhiteman]

This behavior can't be changed as it would cause a catastrophic BC break.  Perhaps a new feature that could be turned on per-instance or per-SC, but this cannot be the new default.

The current behavior also makes sense because it avoids ambiguity. You need to consider cases where a date token is pulled to an earlier date. Does that mean that people still in a wait step jolt forward to the next step, or should they be removed from the flow? Changing token values, too, doesn't mean unambiguously that someone waiting to send to a given alert destination should use the new token.

This is not to say that I don't see the usefulness of a "reset everything on change" type of feature, but it can't replace the current feature.

[Jackie_Patterso]

Hi Sanford,

I'm not really sure what a "catastrophic BC break" is but I do believe wait steps should be reacting in real time. In other Marketing Automation platforms wait steps are reactive in real time. You can also filter, view, and remove people from wait steps in other platforms. This feature is nice because you can make last minute changes.

To my understanding, most tokens are unique and set on the program level and should only affect that program's assets. The example I originally posted was in regards to an event program, that the date changed last minute. Therefore, the leads that were in a wait step, waiting to receive a reminder email using tokens received outdated information and received the email on the wrong day.  We were totally unaware this could happen, because in our previous platform that would not be the case.

We now know that wait steps do not react in real time but we would like them to.

[SanfordWhiteman]

If you change this behavior, it means everyone who relies on this age-old, widely understood behavior suddenly has a possibly catastrophic change ("BC" == "Backward Compatibility"). That's not how professional software platforms need to work.

Creating a new feature that behaves how you want, provided properly specified (there are still cases, as I described above, where the meaning of "reacting" is ambiguous) is fine.