Reading responses

Opening a survey app lands on two pages, switched in the rail on the left: Information - the share link, how many responses have arrived, how many questions are asked, when it closes and whether it is still accepting - and Results, what people answered. Everyone who can open the survey reads both: the form as it was last published and every response. Open editor, the way into the form editor, is offered to whoever may read the survey's configuration - someone who may not change it opens the editor read-only - and building the form needs permission to configure the survey. Someone who may only view the survey never sees the questions being drafted.

Information is the page you open to send the link to someone. The link there is shown only to people who may configure the survey, and it is read-only - copy it - while regenerating it lives in the editor's Settings, behind the same permission, because it invalidates every link already sent. The collection rules are read out the same way for everyone; changing them is done in Settings, and the note saying so is shown only to people who can.

Results is the page you open to read what people said, and it has two readings of the same survey: the Summary, a set of charts built for the form you published, and Individual, one row per response.

Summary

The Summary is a dashboard, built for your survey and kept up to date with it. You do not lay it out: it follows the form. Each of your form's pages becomes a page of charts, with an Overview page in front of them. Questions you ask before the first page break get a page of their own, called Questions. Pick the page in the bar above the charts.

Every question takes one row, in the order the form asks them, and every tile is the same height, so the page reads at one steady rhythm however many options a question offers. The width control in the page header narrows the dashboard to a centred reading column; it is your own preference, the same one the analytics viewer offers, and it follows you from app to app.

The Overview carries four figures - how many responses, how many answers, when the first one arrived and when the last one did - a chart of responses per day, and a bar of how many answers each question drew. Above them sits a filter strip: the time the response arrived, plus a filter for each of the first few single-choice questions your form asks.

Each question then gets the chart its answer type deserves:

• A choice question gets a ring when it offers two or three options and a horizontal bar chart otherwise, over its complete option list - an option nobody picked is still drawn, at zero, because that is worth seeing. A multi-select answer counts once for each option it names, so the bars can add up to more than the number of respondents. If the question allows another answer, the words people typed are listed under the chart.
• A number or scale question gets a distribution, one bar per value given.
• A date question gets a chart over time, because that is what a date answer is.
• A text or email question gets a searchable, sortable table of what people wrote, with its own Export as CSV or Excel. The file holds the answers the table shows - that question's and no other's - under the table's own filters and search.
• A file question lists the file each respondent attached, by name; open the response in Individual to download it.
• A grid question gets a pivot of its rows by its columns.

Questions you have archived get no chart, because they are no longer part of the form; their answers are still in Individual and in the export. Questions you have added to the draft but not yet published get no chart either - the Summary follows the form your respondents are actually answering.

Individual

One row per response, over the same columns an analytics app would see. Click a row to open the record panel, which shows that one person's answers end to end - including the questions they were never shown, marked as not answered so a blank never has to be guessed at.

The grid carries the usual table controls: search, per-column filters, hiding columns, and Export CSV. The time window above it - all time, 7, 30, or 90 days - narrows what the grid and the export read; on the Summary the same question is the filter strip's own control. Downloading the responses is a permission of its own, which comes with the Contributor, Analyst, App builder and Admin roles; someone who may only view the survey reads the answers but is not offered Export CSV.

Deleting a response

From the record panel. Anyone whose role lets them enter data in the survey - Contributor, App builder or Admin - can delete a response and restore it. The delete is reversible: the row is kept and marked deleted, a toast offers Undo, and the audit trail records both halves. A deleted response is excluded from the grid, from the summary, from an export, and from anything an analytics app imports.

Using the answers in an analytics app

A survey app collects answers; it does not transform them. Its pipeline holds only what the platform generates - the responses and the views over them, which the editor's Pipeline page shows read-only - with no SQL to write and nothing to run. That is deliberate, because the job of a form is to be answerable, and every question you could ask of the answers is a question about data. So when you want to join the answers to another dataset, chart them, or feed them into an indicator, you move them into an analytics app, which is where transforms and runs live.

An analytic-app-data node does that. In the analytics app's editor, add one to the pipeline and pick the survey as its source: the source list names every published survey beside your analytic apps, marked (survey), and a survey nobody has published yet is greyed out because there is nothing to import. From there the answers are ordinary pipeline input: a SQL node can filter or reshape them, a Visualisation can chart them, and another app can import the result.

It is a two-step action, and the second step is yours:

1. The node lands on the analytics app's draft, exactly like any node you add by hand. Adding it publishes nothing and runs nothing.
2. Run the pipeline to see the answers flow through it, and publish when the result is what you want.

Because a survey has no runs of its own, the import always reads the responses as they are now, and each run of the importing app captures them into its own immutable history. Deleted responses never travel.