Save, publish, and mobile sync

Audience: Admin

In Form Builder v2, Save is publish. There is no separate “draft vs live” button—the saved definition is what mobile and reports use on the next sync.

What Save does

When you click Save, Chekku:

1. Validates form settings (name, standalone default check-in type if applicable).
2. Persists the full field definition to your workspace.
3. Makes the latest version available to the mobile app and web form responses.

A confirmation dialog explains that saving updates the definition used by the app. After the first save on a new form, the URL includes a stable form ID for sharing and reopening.

Mobile sync timing

Mobile users do not receive changes instantly. The updated form downloads on the next successful sync—when the app connects and pulls configuration updates.

Plan rollouts accordingly:

• Save on the web.
• Ask field testers to open the app on Wi‑Fi or good signal and wait for sync to finish.
• Start visits after sync if you need the new fields immediately.

There is no push notification to phones when a form changes; communicate updates through your team channels.

Layout on mobile

Form Builder supports half-width columns on desktop. On mobile:

• Fields stack vertically in outline order.
• Multi-page forms show one page at a time with next/back navigation.
• Static elements (headers, paragraphs) render like on desktop, adapted to screen width.

Preview with the Mobile viewport in the editor before saving major layout changes.

Unknown or new field keys

The mobile app reads the shared form-definition format. Fields and config keys the current mobile build does not understand are ignored safely—they do not crash the form. v2-only settings inside config degrade gracefully (for example, wide layouts become vertical stacks).

This means:

• New builder features may appear on web before every phone app version supports them.
• Always test on the same app version your field team runs before wide rollout.

Test on a real phone

Emulator preview in the builder is useful but not sufficient. Before production:

1. Save the form.
2. Sync a test device.
3. Start a visit (or standalone submission) with the correct visit type.
4. Fill every required field, including Image and Signature.
5. Submit and verify answers on the web Form responses view.

Repeat after structural changes—new pages, renamed keys, or visit-type required flags.

Tips

• Save incrementally on large forms; edit history helps recover from mistakes.
• Coordinate saves with field hours—mid-route changes can confuse users mid-visit.
• If testers see an old form, confirm sync completed and they are on the right visit type.
• Pair every save with a quick mobile test for forms marked required.

Related links

• Forms overview
• Create a form
• Settings, notifications, visit types
• Filling forms on mobile