Checks
Named ticks on each Submission — “Verified in app”, “Customer told” — with who and when. Independent of Status.
Checks are a facet: every Submission of a Form can carry them. You name them on the Form's Integrations → Checks, one per line and at most eight. On a Submission, a person ticks or clears each one, and who ticked it and when are kept.
They are not Status. Resolving a Submission ticks nothing, and ticking one moves nothing.
A Submission can be addressed and still not verified. Insights
lists those.
The Timeline
Every tick and every clear is an entry on the Submission's Timeline, with the check's name and the person. Clearing a check deletes the tick, but the Timeline keeps both the tick and the clear.
Renaming or removing a check leaves the ticks already made. A tick whose name the Form no longer has can be cleared but not made again.
Over MCP
get_submission returns checks: each of the Form's names, whether it is ticked, by whom
and when. It is null on a Form that does not track checks.
On Insights
A Form that tracks Status and Checks shows its resolved Submissions that still have a check open. See Status.
What did you think of this content?
Status
What the Workspace has done with a Submission. An Integration: per Form, with the Form's own words. A person sets it, with a note saying why; every change goes on the Timeline, fires a webhook, filters the list, leaves with the export, and reads over MCP.
Email both ways. Invitations send a survey's public page and store nothing. Inbound email gives a feedback Form an address; what arrives is stored as a Submission, and status changes answer in the thread.