Skip to main content

Please allow more than 10 calculated fields in a Program.  We use them heavily for both conditional waits and tokens in the emails since calculated fields are dynamic, however, we keep hitting the limit of 10.

@vmallya – commenting on this one for visibility.

Dynamic JO’s branching logic makes me want to build out more multiple email journeys with wait steps between each email, but the need to use the precious calculated fields just to confirm the participant should still receive the email makes it so we might not be able to tokenize everything we need to within one of the templates.

It’d be far more convenient to have all related emails contained within a lifecycle journey, but unfortunately, if we need to use more than 10 calculated fields due to checking if the participant can receive the email, we need to build a separate program.

Curious what the reasoning is for limiting the number of calculated fields available to 10.

For reference, in the Dynamic JO that I’m currently working on (see screenshot below), I already have 6 of the 10 available calculated fields in use, and that’s just to confirm participant details between email steps. If I wanted to tokenize any of the emails with live, up-to-date information, pull in the most up-to-date CSM to send it on their behalf (pulling their email address, full name, and first name), and more, I’d probably be out of luck.

 


@dayn.johnson my imperfect work-around for this scenario is to use a Data Designer for the Participant List and all continuation criteria and using a case statement for exception reason says “none”.  The case statement is useful if different exceptions have different branches they need to follow, for example, if the Company State changes, end the program, if the welcome packet opt out is selected, create a CTA, if None send a follow-up email.  It’s also helpful to add in the AO Participant object to identify participants that are newly eligible and use that as a filter so you don’t get erroneous failures for participants that already joined.  

Still lots of reason to prioritize the request for more than 10 calculated fields, but this might help take the sting out in the meantime.


oh, 100% ​@angela_domenichelli, thanks for the suggestion! I’m working through the logic of this program, and I’m going to be talking to our scaled CS program manager (​@kim_stone) about where in the program I might add an email step in the error routing paths (ex screenshot below) to notify CSMs or our pooled success mailbox.