Data apps
Record types
Creating one
- 1Open Configure → Record types and add one. Name it after the thing, singular: School, Patient, Household.
- 2Choose its identity — which answers decide that two submissions are about the same subject.
- 3Choose which answers are promoted onto the record as attributes.
Identity
Identity is the part worth thinking about. It decides whether tomorrow's visit adds to an existing record or creates a second one for the same school.
| Approach | When it fits |
|---|---|
| An external code | Best when one exists — a UDISE code, a patient number, a registration id. Unambiguous, and it matches whatever system you already run. |
| A combination of answers | Where no code exists. School name plus block plus district, for instance. Choose fields that do not change. |
| No identity | Every session creates a new record. Only right when the subject genuinely is one-off. |
Promoted attributes
A record shows a handful of attributes at the top — the district, the block, the designation. These are promoted from answers on the registering form.
Promote what you would want to see when scanning a list of records, and what you would want to filter by. Everything else stays in the responses and is still readable on the timeline; promoting all of it turns the record header into a second copy of the form.
How a form relates to a record type
Each step form declares its relationship:
| Role | Meaning |
|---|---|
| Registers | This form identifies or creates the record. Usually the first step, and usually where identity fields live. |
| Attaches | This form is filed against a record that already exists in the session. |
| None | The form is not tied to the subject — a session-level note, say. |
Being bound to a record type is also what makes cross-form references legal: a later form can read an answer given on an earlier one for the same record. Without a record type there is no subject to look the value up against.