Forms overview
How Chekku forms connect web design, visit types, and mobile capture.
Video coming soon
Lesson video · forms
id: academy-forms-overview · ~2–4 min
Audience: Admin
Forms are how Chekku collects structured data in the field. You design them in the web Form Builder; mobile users fill them during a visit or as a standalone submission. Saving a form publishes the latest definition so it becomes available on phones after the next sync.
Visit-attached vs standalone forms
Most forms are visit-attached: they appear while a field user is completing a check-in or visit. The form inherits visit context (place, user, visit type) and is stored with that visit record.
A standalone form can be filled without starting a visit. Standalone forms still need a default check-in type so Chekku can classify the submission. Use standalone forms for quick surveys, internal requests, or workflows that do not require a place check-in.
How forms connect to visit types
Every form is linked to one or more check-in types (visit types). That link controls when the form appears on mobile:
- All check-in types — the form is available for every visit type.
- Selected check-in types — only those visit types show the form.
Separately, you can mark a form as required for specific visit types. That is different from marking individual fields as required inside the builder.
| Setting | What it controls |
|---|---|
| Required per visit type | The whole form must be completed before the visit can finish |
| Field required | A single question must be answered when the form is shown |
A visit type can offer several forms; only the ones marked required block completion.
From design to mobile
- Build or edit the form in Form Builder.
- Configure settings: name, notifications, visit types, standalone mode.
- Save — this publishes the definition (there is no separate publish step).
- Mobile users receive the updated form on their next sync.
On mobile, multi-column desktop layouts stack vertically. Fields the mobile app does not recognize are skipped safely; test on a real device before rollout.
Tips
- Attach forms to the visit types your team actually uses—avoid showing every form on every visit.
- Use required per visit type sparingly; too many mandatory forms slow field work.
- Distinguish field required (one answer) from form required (entire form must be submitted).
- Save and sync a test phone after every meaningful change.
- Keep internal field keys stable once forms are in production—renaming breaks reports and integrations.