# Reading responses (/docs/survey-apps/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 [#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.

<Callout type="info" title="What the filter strip covers">
  Narrowing there narrows the four figures and the two charts **on the Overview
  page** - so you can read the whole picture for one team, one site, or one month.
  It does not reach the per-question charts on the pages after it: those are drawn
  over the complete option list of each question, including the options nobody
  picked, which is a different question from "what did this team say". To read one
  group's answers question by question, take the answers into an analytics app -
  see the end of this page.
</Callout>

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.

<Callout type="info" title="One question, one measurement">
  If you change what a question MEASURES - a scale's end points, whether it is
  required, who it is shown to - the answers given before and after are not the same
  measurement. The charts count only the current one; the earlier answers are still
  in Individual, in the record panel and in the export. Correcting the WORDING of a
  question changes nothing: all of those answers are still comparable.
</Callout>

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 [#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 [#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 [#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*&#x2A; 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 &#x2A;(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.