Allow customizable number of hours for recurrent evaluate steps in new dynamic JO

We also feel that the change to hard code a wait period of 11 hours is totally a problem in the new JO.

In fact, this rolling back of functionality makes the new version of JO borderline not usable for us anymore.

Product team, you REMOVED a feature which was a make or break feature of JO for us and others.

Please, RESTORE the ability to customize hours instead of hardcoding it at 11 hours.

Great question in the GGA community today (thank you @stevepost) reminded me about this idea, checking back in to see if this is on the roadmap with the rest of the (highly necessary) dynamic JO improvements needed such as :

Wen you use an Evaluate step that runs multiple times to check a condition, it checks every 11 hours to test for your criteria. For participants that are held in the evaluate step until a condition is met, does anyone know how to check when the evaluate will next check the condition?

The current messy workaround is to:

• Check the “Participant Criteria Step Execution" in the MDA source
• Add 11 hours to the latest entry in that object for each email address to estimate when the next evaluate should occur

It shouldn’t be this convoluted to calculate when a participant will qualify to pass through an evaluate step. We can’t be the only ones having this issue. @K_C_, can we get some eyes on this?

Other dynamic JO issues (which make it a non-starter for us) include:

• Dynamic JO needs additional data types if we are not allowed to do Custom Field Mapping. Discovery
• 28 Votes

• New JO: log to timeline all emails by default New Idea
• 11 Votes

@marymcbride For clarity, the 11 hour topic is not a recent change. It’s been around for a long while now and was not resolved in advanced. What you could configure in advanced is for how long it will re-evaluate the conditions, but it will still re-evaluate them every 11 hours. In Dynamic you can still set the length of the period you want the condition to be evaluated during, and within that period, it will still be re-evaluated every 11 hours. No change. 

Finally, as far as workarounds go, Dynamic actually offers a great feature to circumvent the “weird o’clock” email issues: participant timezone, for which you set the timezone for each participant (it’s a bit of initial effort, but it’s very much worth that effort), and you set the timespan you want emails to be sent during and the days of the week.

And boom, no issue with weird o’clock emails anymore. 

Truth, @alizee -- that bit is referenced here (current “advanced” JO support documentation):

Note: When referring to a Calculated Field, if the configured Time Limit of the Conditional Wait is less than 24 hours, then the calculated field is evaluated at the end of the time period. If the configured Time Limit is more than 24 hours, then the field is evaluated every 11 hours.

The ask in this idea is for more control over how frequently that conditional wait is evaluated.

I suppose a (non-elegant) solution would be to daisy chain a single evaluation into a wait timer and bring it back through the evaluate step, but that feels like a lot of extra effort and potential for breakage.

Action execution schedule and participant timezone -- yes, definitely one of my wishlist features for us to be able to use. Checking back in internally -- @kstim for vis -- but earlier this year, we didn’t have an API set up to (or prioritized) to get user-level timezones (or language preference). 

Absolutely agree though, the action execution schedule is definitely the way to go for dynamic programs if you’ve got accurate participant timezone information -- think that’s gonna go up on my priority list!