Skip to content

Viewing submissions

Every time someone submits one of your published forms, a row lands in the submissions table for that form. This page is where you read them, triage them, and pull them out as CSV when you need to share with a leader.

Submissions table

Getting there

From the Forms list, click any form's row to open its builder. In the top right, click Submissions — or use the URL pattern /forms/{form-id}/submissions directly.

The page header shows the form's name, the total submission count (badge), the status filter, and an Export CSV button.

The table

The submissions table shows, in priority order:

ColumnWhat's in it
Checkbox for bulk actions
DateWhen the submission landed (formatted in your org's date locale)
NameThe submitter's name (pulled from the first Text field labelled "name" — or blank/italicized "Anonymous" if none)
EmailThe submitter's email (pulled from the first Email field with a value)
StatusColoured badge — new, read, starred, or archived
(up to 3 preview fields)The first three non-display fields by sort order — truncated to 40 characters
Row-level dropdown

Mobile shrinks this to a card layout — name + status badge on top, email and date below, and the first two preview fields stacked under that.

Statuses

Every submission starts at status new. Statuses are purely organizational — they don't affect anything else in GCM, they're just a way of tracking which submissions you've dealt with.

StatusWhen to use it
newDefault. The submission just landed and nobody's looked at it.
readYou've opened the submission. GCM auto-marks new → read the moment you click into the detail view.
starredYou're flagging this one as important — usually because it needs a follow-up.
archivedYou've actioned it (or decided not to) and don't need to see it in the default view.

Filter by status using the dropdown in the page header. Default is "All."

Viewing a single submission

Click any row to open the detail modal:

Submission detail

You see every field's label and the value the visitor entered, in form-order. File uploads show as download links. Empty fields show as -- so you know whether the visitor skipped them or actually submitted an empty value.

The detail modal is read-only — submissions can't be edited. If a visitor needs to correct something, ask them to submit again.

Bulk actions

Tick a checkbox in any row to enter bulk-select mode. A bar appears above the table:

  • Mark read — bump every selected new to read
  • Star — flag all selected as starred
  • Archive — bump all selected to archived
  • Delete — permanently remove the selected submissions (with a confirmation modal)

Tick the header checkbox to select every row on the current page (not every row in the form — just what's visible).

Delete is permanent

Soft-delete doesn't apply to submissions — when you delete, the row is gone for good. If you need an audit trail, export to CSV first.

Exporting to CSV

Click Export CSV in the page header to download every submission currently in view (after the status filter, but ignoring pagination — all matching rows export, not just the visible page).

The CSV columns are:

  1. Date — created timestamp in your locale
  2. Name — submitter name
  3. Email — submitter email
  4. Status
  5. One column per non-display field, in form order, using the field's label as the column header

Multi-value fields (checkboxes with options, multi-select) are joined with ; . File-upload fields export the storage path, not a downloadable link.

The file is named {form-name}-submissions.csv. Open it in any spreadsheet — Excel, Google Sheets, Numbers — and you're done.

Single-row actions

The ⋮ icon at the end of each row opens a small menu:

  • View — same as clicking the row
  • Star — flip status to starred
  • Archive — flip status to archived
  • Delete — same delete flow as bulk delete, just for one row

Empty state

If a form has no submissions yet, the page shows a friendly empty state — clipboard icon, "No submissions yet," and a hint that submissions will land here once people start filling out the form. Once the first submission lands, the empty state disappears automatically.

What about real-time?

The page doesn't auto-refresh — you'll need to reload to see new submissions land. If you want a notification the moment a submission comes in (push, SMS, email), build a workflow with the form.submitted trigger. The workflow integration article covers exactly that flow.

Privacy and retention

Submissions stick around forever by default. There's no auto-deletion. If your org needs a retention policy ("delete prayer requests after 90 days"), you can:

  • Set up a manual quarterly cleanup ritual — filter by date, bulk-select, delete
  • Build a scheduled workflow that finds old submissions and deletes them (advanced)

The data itself sits in the form_submissions table inside your org's row-level-security scope — only your admins can read it, and only the platform itself can read it system-wide. See the users & roles docs for who has access to what.