Record types
Why this matters more than it sounds like it should
Imagine two field officers, a week apart, both visit “Govt. Primary School, Bilaspur”. Should that second visit land on the same school record as the first, or create a brand new one? Get this wrong and a school's history silently splits in two — half its visits under one record, half under a duplicate, and nobody notices until someone asks “why does this school only show one visit this year?”
The record type is where that question gets answered once, correctly, instead of being left to whatever a field officer happens to type into a name field each time.
Creating one, step by step
- 1Open Configure → Record types and add one. Name it after the thing itself, singular — School, Patient, Household — not after the form that collects it.
- 2Choose its matching & display settings — the rule that decides whether a new submission belongs to a record that already exists, or starts a new one.
- 3Choose which answers should show up on the record as key details — the handful of facts worth seeing at a glance without opening the full history.
Matching: the one setting worth thinking hard about
This single choice decides whether tomorrow's visit adds to the school that already exists, or quietly creates a second, disconnected one for the same place.
| Approach | When it fits |
|---|---|
| An existing ID | Best whenever one already exists — a UDISE code, a patient number, a registration ID. Unambiguous, and it lines up with whatever system your organization already keeps. |
| A combination of answers | Used when one answer is not enough — school + class + roll number for a student, say, because two schools can both have a “Class 5, roll 12”. A blank part is not accepted, and the same combination cannot be registered twice. Pick answers that genuinely will not change. |
| No matching rule | Every session creates a brand-new record, with nothing carried forward. Only the right choice when each session really is a one-off, with nothing to accumulate. |
Linking two record types (school and students)
A programme can have a second record type above the main one — the school the students belong to. They are joined by one answer both carry, such as the school code. Both record types list that answer under Details to show & search by, and the upper one is identified by it alone. The app checks this when you save and tells you in plain words what is missing. See Programmes with schools and students for the full walk-through.
Key details: what shows up at a glance
Open any record and a handful of details sit at the top before you even look at its history — the district, the block, the designation. These are chosen from answers given on whichever form registers the record.
Pick what you would actually want to see while scanning a long list of records, and what you would want to filter by — a district, say. Everything else is still there and still readable in the full timeline; choosing every single field here just turns the record header into a second, cluttered copy of the form itself.
How a form actually relates to a record type
Each step form declares its own relationship to the record type it belongs to:
| Role | What it means in practice |
|---|---|
| Registers | This form is the one that identifies or creates the record — usually the first step, and usually where the identifying details actually live. |
| Attaches | This form is filed against a record that already exists by the time this step runs, within the same session. |
| None | This form is not tied to any record at all — a session-level note that does not belong to any one subject. |
Being linked to a record type is also what makes it possible for a later form to read back an answer given on an earlier one, for that same record — a district typed once at registration, reused automatically on every visit afterward. Without a record type there is nothing for that later answer to be looked up against.