Hi,
we have a setup where we need a sequence of dependent field that are hiding each other:
Field1 (Boolean) is a masterfield for Field2, Field2 is hidden&cleared when Field1 = false.
Field2 is an enum and a masterfield for Field3, Field4 which are each displayed for acertain value of Field2 and hidden&cleared otherwise.
This was implemented with 2023.06 with dependent fields, using the hide&clear feature.
We are updating to 2024.06 now and if I use a notRelevant feature instead of hide&clear, my Field3 and Field4 are not behaving as they should anymore: If I first set Field1 to true, then Field2 is displayed and I can select a value for it, depending on that value either Field3 or Field4 is displayed. Works fine.
If I now set Field1 to false, then Field2 is hidden → ok
Field3/Field4 is still displayed in the UI, though. If I then save my form and re-open it, then Field3/Field4 are hidden, as I would want them.
What would be possible options to tackle this problem?
Thanks!
Jana
Hi @jana-dark-core
The way to solve this problem is to avoid modeling a chain of dependencies. What I mean by this is that Field2 is in the middle of a chain.
- Field1 can hide and clear Field2
- Field2 can hide and clear Field3 and Field 4
You need to resolve this chain by modeling a Computed Field that considers the values of both Field1 and Field2. This then provides the solid foundation on which you can model your dependency for Field3 and Field4.
As Hide & Clear dependencies are automatically migrated to NotRelevant, you don’t need to make any further modeling changes.
Note on Booleans
When migrating to 2024.06, you should also consider that boolean coalesing is deprecated. You should consider changing your boolean triggers to confirms to achieve consistent 2-value logic.
Example Models
2023.06-ext6
DependenciesInAChain_DM.json (6.7 KB)
DependenciesInAChain_FM.json (3.9 KB)
These models can be tested in 2023.06-ext6 and then migrated to 2024.06 with no change in the functionality. The key is the computed trigger field that considers the values of Field1 and Field2.
fyi, there’s a Monthly Modeling Highlight on Dependencies from 2023 that you can find on our e-Learning platforms.
We make the same recommendation there and you can watch the video to get more insight.
The Modeling Release presentation for 2024.06 is also available on the e-Learning platforms and talks about both the migration:
- Hide & Clear to NotRelevant
- Booleans and Confirms
To be honest, though, it feels kind of strange and like unnecessary additional work to introduce hepler fields aka computed trigger fields just to be able to handle visibility of a fields in the UI 
Plus, it’s additionally cluttering our models and in this specific project we are already struggling with performance of SME due to big & many models.
Is there an alternative to introducing a computed trigger field?
The use-case that you presented was hiding controls and clearing the values in them.
The computed trigger is recommended as this considers all the data that could affect whether Field3 and Field 4 should be filled or cleared. This also means that the dependency can be triggered after a single calculation is completed.
The solution that you used in 2023.06 relies on a chain of dependencies. This meant that the Form Engine needed to iterate through your dependencies in the correct order to reach the correct result that you are looking for. This can lead to long chains which can then cause poor performance. An example of where this can be found in Performance issue in form with many repeat entries.
By following the recommendations that I made above and also migrating to 2024.06 significant performance improvements can be made, partly because the Form Engine no-longer iterates through your models in the same way.
I hope you also notice the performance benefits after migration.
An alternative if you only need to hide the fields would be to model a Dependent Control. Please note, that the Control and Element to be hidden need to be on the same screen.