Build an app, step by step
What we are building — a field monitoring app
A field team visits schools on a quarterly cycle. The same school is visited again and again, issues get logged in between visits, and at the end of a quarter someone needs to see one school's whole history on one page rather than three separate response lists. That is exactly the shape an app exists for.
1. The record type — School
- 1Create a record type named School.
- 2Set its matching & display settingsto the school's UDISE code when one is captured, falling back to the combination of school name, block and district when it is not — a real decision, not every field, and one that does not change between visits.
- 3Choose
district,blockandschool_nameas key details, so a list of Schools is scannable without opening each one.
2. Step one — School details (registers the record, once)
The first step is what creates the record. It runs once per school, ever — visiting the same school again does not create a second one. Adding the record type's registration form as the very first step sets How many times to Filled once automatically — this is the one setting you do not need to touch yourself.
Step 1 — School details
District
Select an option · dropdown list: districts
Block
Select an option · cascades from District
School name
Select an option · cascades from Block
UDISE code
Short answer · official code, if known
2. Step two — Quarterly training visit (repeats, once per period)
The second step is filed against the school this session resolved to in step one. It is Repeatable, and three settings together are what turn “repeatable” into “exactly one training visit per school, per quarter” — a real constraint the server enforces, not a convention field workers are trusted to follow:
| Setting | Set to | Why |
|---|---|---|
| Counted per | Record, per cycle | The count resets at the start of each reporting cycle, rather than growing forever or resetting every time the app is opened. |
| Response count | 1 to 1 | Exactly one entry is required, and a second attempt within the same cycle is rejected rather than silently added as a duplicate. |
| Date this happened | Visit date | Orders this entry on the school's timeline by the real visit date, not by whenever it happened to be typed up. |
Step 2 — Quarterly training visit
Visit date
Date
District
Short answer · read-only, filled from the registration step
Topics covered
Choose all that apply
Attendance count
Number
The read-only District field is the piece that ties the two steps together — it is not re-asked, it is read back:
3. Step three — Site issue log (optional, repeats, no duplicate date)
Not every visit turns up an issue, and an issue can be logged between visits, not only during one — so this step is Optional and, unlike step two, Counted per is set to plain Record: the whole history, not just the current cycle, since an issue is not tied to a reporting window the way a scheduled visit is.
Step 3 — Site issue log
Issue date
Date
Description
Long answer
Resolved
Choose one · Yes / No
Photo
File upload
What the record shows afterward
Open the School record for this school and the three steps appear as one timeline, newest first: every quarterly visit, every issue logged in between, each response showing the form it came from and when it arrived. District, block and school name sit at the top as the key details chosen in step one — the same three fields on every visit and issue response, without re-typing them each time.
Next quarter, the same public link resolves to the same record, step two opens again because a new window is open, and step one does not — the school is already registered.
Go deeper
The app builder
The top bar, the basics, steps and dashboard cards, and the live preview.
Record types
Defining the kind of thing an app collects data about, and how it's matched and displayed.
Steps
Ordering forms, repeating them, and making them conditional.
Records and timeline
Reading everything collected about one record in one place.