Records

A record is one submission of a published form. Records arrive from two places: the mobile app (the most common path for field work) and the API.

What a record carries

Beyond the captured field values, every record stores metadata about how it was made:

Because the form version is stored on the record, changing a form later never changes how existing records read. What a new version means for older records — when they appear together and when they stay apart — is covered in form versions.

Statuses on the device

On a mobile device, a record moves through four statuses:

Drafts and queued submissions live on the device and survive app restarts and missing signal — see the mobile app guide for how sync works. In the app's own lists, submitted shows an upload-pending cloud icon: only synced means the record has reached the platform.

A submitted record has not left the device yet, so the field user can unlock it back to draft to fix a mistake before it uploads. A record that has reached the platform (synced) or hit a sync error cannot be unlocked this way — a synced record is already on the server, and an errored one keeps its resolve-first flow.

Reviewing records in the dashboard

The dashboard has two views:

• Records — one row per form, each with its record count and a per-version breakdown, so you can see at a glance how a form's records are spread across its published versions.
• Per-form records — the records for one form, with text search, a version filter, and a column picker so you can show exactly the fields you care about. Each form's display fields provide the one-line summary shown in lists.

The per-form view defaults to All versions, so records captured under older versions of the form appear alongside new ones. A version column shows each record's version; a filled badge marks records not compatible with the form's current version — a visible seam, not an error. The version filter lists only the versions that actually hold records. See form versions for what compatible means.

Opening a record shows every captured value plus the submission metadata above. When a record's version is not compatible with the current one, its page says so in a short notice — the record still reads normally against the version it was captured with. Records can be deleted through the API; the dashboard does not offer deletion. A checked-out record cannot be deleted until its dispatch ends. Who can edit records is covered in role-based access.

Dispatching a record back to the field

Sometimes a submitted record needs a second visit — a follow-up inspection, a work order picked up the next morning, a compliance recheck. Dispatch checks an existing record out to one field user so they can finish it offline.

On a record's detail page, the Dispatch card lets you pick the user, set an optional due date, and add optional notes. The next time that user's device syncs, the record arrives with all of its photos and other media, ready to edit with no connection. When they resubmit, the updated record replaces the original and the checkout ends.

If the record's version is not compatible with the form's current version, the Dispatch card says so before you send it: the record will be filled and returned under its own version, not the current one. Dispatch still works — the notice is there so the difference does not surprise anyone.

While a record is checked out:

• It is locked. No one else can change it — not from the dashboard, not from a device, and not through the API — until the field user resubmits or you revoke the dispatch. This keeps exactly one person working on the record at a time.
• Its state is visible. The record's page shows who has it, when their device downloaded it, the due date, and the notes. Records tables show a Checked out badge, and a filter narrows the list to checked-out records or hides them.
• You can take it back. The Revoke button on the record's page ends the checkout. The copy on the user's device becomes read-only and will not upload; the record unlocks for everyone else.

The due date is a reminder for the field user, not an enforcement — a record past due stays checked out until it is resubmitted or revoked.

Who can dispatch: organization admins always can. Other users need the Dispatch setting on their form assignment, described in user management, and they can only dispatch records they can view. The receiving user must be assigned to collect with the record's form.

When a dispatched record is resubmitted, it fires the record.updated webhook event, so downstream systems see the new values. Dispatch and revoke are also available through the API for building your own assignment workflows.

What happens after submission

When a record lands, the platform can act on it:

• Webhooks — a record.created event fires to any active subscription, so your other systems learn about the submission within about a minute. See webhooks.
• Reports — a webhook wired to a report template turns the record into a finished file and emails it. See reports.
• API — pull records on your own schedule through the REST API, with pagination for large sets.

One caveat worth knowing up front: records created through the API do not fire webhooks. The reasoning is covered in webhooks and the API.