Using top-level nested values in form conditions
It would be fantastic to add multiple prerequisites to the same form condition, as suggested here.
Additionally, this would be very helpful for conditions that rely on fields with nested values. For instance, say you have [category]::[options 1/2/3], rather than needing 3 clones of the same conditions, it would be better to just use [category], or one trigger with ANY conditions that include [category]::[options 1/2/3].
We have 20 different types of contracts organized in a field, 12 types are nested under 3 categories (split across them 2/6/4), the remaining 8 as standalone options at the top-level. Once they select one, the resulting set of conditional fields will be based on the 3 categories. That said, many people won't know what they need among the categories, so we need to present the 8 on their own.
For instance, they know they need an NDA, but don't know what category it falls into. If we present the 3 categories, they would guess at one, then look through the types to see if the one they're looking for is there. If it's not they'll need to go back a question, guess again, and hope again - repeat for as many categories as there are.
Suffice it to say, the minimum #conditions could be 3+8 - if the 3 categories (and their nested type options) could cover their respective 12 options. Instead you need to set up clones for each of the 12, totaling all 20.
Using the top level of nested options would save admin time, reduce backend clutter, rework, and maintenance, and minimize errors from cloning/duplicating work.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
0 Kommentare