What a data app is

A monitoring visit records the school, the training delivered, and what was observed in three separate blocks. As three forms, someone fills them one after another and nothing ties them together — you end up with three response lists and a spreadsheet exercise to rejoin them.

As an app, they are three stepsof one session, all filed against that school's record. The record then shows the whole history in order, and next quarter's visit adds to it rather than starting again.

• A record type — the kind of thing being measured, and what identifies one.
• Steps — the forms, in order, each with a cardinality and an optional condition.
• A public link of its own, its own theme, and its own access rules.
• Periods — optional reporting windows, so an app can be open only during a quarter.

A respondent opens the app's link, identifies or creates the record, then works through the steps — either on one page or a step at a time, depending on how the app is set up. Progress can be saved and resumed if drafts are allowed. On submit, every step becomes a response against that record, all bound to the same session.

Validation runs across the whole session, so problems in step one and step three are reported together rather than one screen at a time. Nothing is filed until it all passes: a half-submitted report, where some entries landed and others did not, is worse than a rejected one, because there is no way to tell which is which.

How the steps are paged, how wide the page runs and how it is dressed are covered in App appearance.

An app requires sign-in by default, where a form does not. An app writes to a registry, which is a heavier act than answering a survey, and the safe default for something that creates records is closed. Change it in App settings → Access if the app is genuinely public.