Option lists
Cascading and lookups
Cascading dropdowns
Choosing a state should leave only that state's districts on offer. That is a cascade, and it is a property of the lists rather than of any one form — build it once and every form that uses both lists gets it.
- 1Create the parent list first —
in-states, say — and upload its items. - 2Create the child list and set Cascades from to the parent.
- 3Upload the child's items with a parent valuecolumn. Each row names the parent item it sits under, using the parent's value — not its label.
- 4In the builder, bind one question to the parent list and another to the child. The child question asks which question supplies its parent answer.
What a respondent sees
| State | Behaviour |
|---|---|
| Parent not answered | The child says "Choose {the parent question} first" rather than rendering an empty dropdown. An empty dropdown is the single most confusing thing here — there is no way to tell loading from broken from waiting. |
| Parent answered | The child loads only the items under that parent. |
| Parent changed | The child reloads and its own answer is cleared. A block left selected under a newly chosen district would be a combination the server rejects at submit. |
| Long child list | Above about thirty options the control becomes searchable and filters on the server as the respondent types, so a school registry never has to be sent to the browser. |
Depth
Cascades chain: state → district → block → school. Each list names one parent, which is exactly what a dependent dropdown needs. A list cannot be its own ancestor — a ring would make the cascade query loop, so it is refused when you set the parent.
A list that others cascade from cannot be deleted while they do. Detach the children first; otherwise every one of them would become unreachable and every question bound to them silently empty.
Lookups: auto-filling from a chosen option
Extra columns uploaded alongside a list stay attached to each item, and a calculate rule can read them with lookup().
The usual case: your school list carries a UDISE code. Add a read-only “UDISE code” question and a calculate rule that looks it up from the school question. The moment a school is chosen the code appears. No second dropdown, no transcription error, and no way for the two to disagree.
Anything scalar works — a pincode, a category, a designation, a contact number. Declare the columns on the list so the rule editor can offer them by name, and map them during upload.
Designing values that last
A value is a join key. Once responses reference it, changing it orphans them. Two rules keep you out of trouble:
Make values stable — derive them from something that does not change, not from a row number that shifts when the file is re-sorted.
Make them unique across the whole list, not just within a parent. Two states both have a Bilaspur, so a district value of bilaspur collides; HP-bilaspur and CG-bilaspur do not.