Publishing and responses
Responses
The response list
Responses lists every submission, newest first, across all versions of the form. Open one to see its answers laid out against the questions of the version it was filed against — so a response from before you reworded a question still reads correctly.
An answer whose question no longer exists is still shown, marked as removed, rather than dropped. Silently hiding submitted data is worse than an unfamiliar label.
Response statuses
| Status | Meaning |
|---|---|
| Submitted | Accepted and stored. The normal case. |
| Flagged as spam | Caught by the honeypot or CAPTCHA. Kept rather than discarded so you can check the filter is not over-eager. |
| Rejected | Failed validation at ingest and was not stored as a normal response. |
| Deleted | Soft-deleted. Removed from the list; recoverable. |
Exporting
Export the set as CSV or Excel. One row per response, one column per question, using labels as headers. Multi-select answers become a delimited list; uploaded files become a reference.
Responses inside a data app
When a form is part of a data app, its responses also appear on the record they were filed against. The record's timeline shows every entry in order, and opening one shows that response in place, with previous and next to step through the rest — so reviewing everything collected about one school does not mean visiting each form's response list in turn.
Deleting
Deleting a response is a soft delete. It leaves the list and the exports; it is not immediately destroyed. Deleting the form does not delete its responses — the form goes to Trash and the data stays with it, which is why restoring a form restores everything collected through it.
Who can see what
| Role | Responses |
|---|---|
| Viewer | Read and export. |
| Editor | Read, export and delete. |
| Admin | Everything an editor can do. |
Responses never cross organizations. Every read is scoped to the workspace you are in, checked on the server rather than filtered in the browser.