# Answering a round (/docs/indicator-apps/questionnaire)



**You open the questionnaire from a round.** Go to the indicator app's **Collection**
tab and press **Answer** on the row naming the round and the reporting unit you want
to fill in - one row per pair, so being responsible for several units is several
rows, not a second menu. That takes you into the guided form: the app's questions,
one section at a time, so you never have to understand how the app is built to fill
it in. See [Collection rounds](./collection-rounds.mdx) for how a round is set up and what that table
shows.

The questionnaire is always about ONE round, and about the reporting units you were
asked for - both come from the round and your own assignments rather than from
anything you choose here. **The round fixes the reporting period**, so there is no
period picker on this screen, and it narrows the questions to the ones your units are
actually asked. Somebody responsible for two sites answers both in one questionnaire,
with a column for each. If nobody has asked you anything yet, there is no **Tasks**
entry in the navigation at all.

**A round you were asked on shows up only once you can edit that app's data.** Being
assigned to a unit says what you answer for, not that you may open the app. If you
expected a round and do not see it, or opening it says the round is not there, ask a
workspace administrator for access to the app - Contributor or wider is what
answering needs.

If you only want to read or correct a figure - and your workspace has given you
permission to - the **Data** tab is the other way in: it shows one datapoint's
record, its configuration and its figures over time, rather than a form. An app that
runs no round at all collects entirely through that tab.

## Finding your way around [#finding-your-way-around]

The page has two halves.

On the **left** is your progress and your map:

* an **Overall completeness** card, with a progress ring and the plain count of how
  many required items are done, for example "12 of 20 required complete",
* a search box over the sections and questions, and
* one card per section, each showing its own completion and, when you open it, its
  questions as a list. Clicking a section switches the form to it; clicking a
  question scrolls straight to it.

You can hide the whole rail with **Hide sections** when you want the form full
width; Ovidens remembers the choice, and which sections you left folded.

On the **right** is the form itself: the current section as a stack of question
rows, with **Section 3 of 8** above it and **Previous section** / **Next section**
buttons to move through them.

## A question row [#a-question-row]

Each row frames one datapoint: its number and name, a marker if it is required, its
unit, and any guidance the app author wrote for it. Beside that sits its status:
**Required**, **Complete**, **Optional**, **Not applicable**, or **Trigger unknown**.

The last two are worth knowing. An app can make a question conditional, so it is
only asked when something else is true. When the condition is false you see "Not
applicable" with the reason spelled out, instead of being asked for a number you do
not have. When the condition depends on an answer nobody has given yet, the question
stays open and is marked "Trigger unknown" rather than being quietly hidden. A whole
section can be conditional the same way.

The value control matches the kind of datapoint: a number box, a text box, a
yes/no, a dropdown, or a file upload. Values save as you go, with a small
**Saving…** then **Saved** next to the field, and **Clear** empties one again.

### Last year's number [#last-years-number]

Next to a value sits a small clock. Hover it and you see what this exact figure was
in the preceding calendar years, most recent first, up to three years back. It only
appears when there is history to show, and it reads the same on a single figure as
on every cell of a breakdown.

### Comments [#comments]

**Add comment** attaches a note to a value: why the number moved, what was excluded,
where it came from. Some questions require one, and then the app tells you. A value
that carries a comment shows it, and **Edit comment** or **Remove** change it later.

### Questions with a breakdown [#questions-with-a-breakdown]

If a datapoint is broken down by a [dimension](./dimensions/other-dimensions.mdx),
for example per site, the row holds a small grid instead of a single box: one line
per breakdown member, with a **Total** so you can see the figures add up. The grid
shows your own reporting unit and anything beneath it, and nobody else's. A
**required** breakdown counts as complete only when every one of its cells holds a
figure, in every period of the reporting window - a cell marked not applicable is
the one legitimate gap. An optional breakdown is looser: one figure per period is
enough. Each cell in that grid takes its own comment, and an empty one offers
**Carry forward from last year**, which copies the previous window's figure across
and marks the cell so reviewers can see where it came from.

When a breakdown is too large to be comfortable inline, **Edit breakdown** takes you
into the editor's full data grid for that datapoint and period, where the same
values are editable with more room.

## When a question cannot be answered here [#when-a-question-cannot-be-answered-here]

A datapoint collects at its own cadence - monthly, quarterly, yearly. If the round's
reporting period does not contain a whole period at that cadence, the question tells
you so rather than accepting a figure that would not mean anything. An administrator or a
reporting manager of the app fixes that by creating a reporting period that covers it.

An answer that has been **approved** is frozen, for everybody including an
administrator: the notice above it says who decided and when, and only a reviewer
reopening it makes it writable again. An answer **sent back for
changes** is the opposite - it is open again, with the reviewer's reason beside the
question so you know what to fix.