Dynamic Conditional Form

A conditional form whose content or conditions are determined as the form is used rather than fixed when it was designed.

Where to find it

Architect Panel → Data:

• Datastores — the datastore, then Table Designer to add or edit a field

How it differs

An ordinary conditional form has sections defined in advance, shown or hidden by a condition. This one can determine what to show at the time — driven by data, by earlier answers, or by something looked up while the form is open.

When the extra capability is warranted

• The questions depend on data that changes — a product's options, a scheme's current rules.
• The set of sections is genuinely open-ended rather than a fixed list.
• Maintaining every variation as a separate static section would be unmanageable.

And when it is not

If the variations are known and stable, use the static conditional form. It is easier to reason about, easier to test, and visible in the field configuration rather than determined at runtime.

Dynamic behaviour is harder to support: when somebody reports that a section did not appear, you are reconstructing what the data looked like at that moment rather than reading a rule.

Test with real variety

Because the form differs by situation, testing one path proves very little. Work through a genuine spread of cases, including the awkward ones — the record with nothing configured, the one with far more options than expected.

Think about what happens when the source changes

If the sections depend on data, that data will change. A form completed last year may have asked questions that no longer exist, and a record may hold answers to questions the form would not ask today.

That is not wrong — it is history — but reports comparing across time need to expect it, and somebody reading an old record needs to understand why it looks different.

Keep it explicable

Somebody will eventually ask why a particular person saw a particular set of questions. Make sure that is answerable — from configuration, from data, or from something recorded at the time.

A form whose behaviour cannot be explained after the fact is a problem in any regulated context, and uncomfortable in every other.

Performance matters more here

Working out what to show takes effort, and it happens while somebody waits. If the form feels slow, that is a user-facing problem — check what the dynamic logic is doing rather than accepting it.

Worked example

An application form shows sections based on which funding scheme was selected, with schemes and their questions held as data so the team can add one without a change request. When a scheme's questions are revised, older applications still show what was asked at the time — a behaviour deliberately chosen and written down, so nobody reads it as a fault.

Recommendations

• Use the static version where the variations are known.
• Test a real spread of cases, not one path.
• Make the behaviour explicable after the fact.
• Expect historical records to differ, and say so.