Showing Fields Conditionally
A custom field that only applies sometimes should only appear sometimes.
Where to find it
Architect Panel → Forms:
- Custom Fields — the custom field definitions
- Conditional Forms — the show and hide rules
Architect Panel → Security:
- Permissions — restricting who may see a value
Why it matters
Fields accumulate, and most of them apply to a minority of records. A form showing all of them asks everybody about circumstances that do not apply to them, and the answer to a question that does not apply is usually wrong rather than blank.
Drive it from a defined choice
The field controlling visibility should be a constrained option, not free text. A rule matching "Yes" fails on "yes", "Y" and a trailing space, and the symptom is a field that appears for some people and not others with no discernible pattern.
Show groups, not individual fields
Where several fields apply in the same circumstance, reveal them together. One rule showing a section is easier to read, easier to change and much easier to test than six rules doing the same thing.
Match required to visible
A field that is required and hidden is a form that cannot be submitted, with nothing on screen explaining why. It presents to the user as a submit button that does nothing, and it is the commonest fault in conditional forms.
A field should be required exactly when it is shown.
Decide what happens to an answer that gets hidden
Somebody answers, changes an earlier answer, and the question disappears. Is the answer kept or cleared? Both behaviours exist; the wrong one either resurrects an answer unexpectedly or silently loses work.
Decide once, and be consistent across your forms.
Hiding is not security
The caution worth repeating. A hidden field is hidden in the interface. It is not protected, and it is still there in exports, in the API and in reports.
If somebody must not see a value, that is field security. Conditional display is about relevance, not access.
Keep the rules few
Three simple rules are comprehensible. Fifteen interacting ones produce behaviour nobody can predict, including whoever wrote them — and the way you find out is a user reporting that a field "sometimes" appears.
Test every combination
Each value of the deciding field, end to end, including changing your mind part way. That last path is where conditional fields go wrong.
Worked example
A case form shows one of three field groups depending on case type, using three rules on a constrained field. Testing the change-your-mind path found a hidden field still blocking submission, which was corrected before release.
Recommendations
- Drive rules from constrained choices.
- Reveal groups rather than individual fields.
- Required exactly when shown.
- Never use hiding as a security control.