# Collection Overview (/docs/indicator-apps/collection-overview)



**Collection Overview** answers one question at a glance: how is data collection
going? Open an indicator app and it is the first thing you land on, on the
**Overview** tab, beside **Questionnaire** and **Contributors**. It shows
completeness, who is contributing, and where the gaps are, all in one place.

It is built for you from the data you collect, and there is nothing to configure.
The time window comes from the **reporting period** you pick in the header, which
is shared with the other two tabs; the app derives its periods from its reporting
interval, so there is always one to pick. Beyond that you only have a **group filter** and a
**Refresh** button, and, on the heatmap itself, a **View** control that sets how
fine the columns are.

## The headline numbers [#the-headline-numbers]

Across the top sit three summary cards:

* **Overall completeness** - the share of expected values that have actually been
  collected, with the filled and expected cell counts behind it.
* **Active contributors** - how many people have entered data, so you can see
  collection is a shared effort and not resting on one person.
* A combined card for what needs attention: how many indicators are **Overdue**, how
  many are **Indicators at risk** (below 50% complete), and when the **Last entry**
  was made.

## Find the gaps [#find-the-gaps]

Below the headline numbers, several panels show where collection needs attention:

* **Completeness heatmap** - a grid of indicators against periods, coloured from
  well-covered to empty. Filter it by group, search by name, expand or collapse
  groups, change the column resolution with **View**, and open it **Fullscreen**
  for a busy app.
* **Coverage by dimension** - for indicators broken down by a
  [dimension](./dimensions/other-dimensions.mdx), bars showing how complete each
  member is, worst first, so a lagging region or site stands out.
* **At-risk & overdue** - a short table of the least-complete indicators, with how
  many of their expected values are in.
* **Submission trend** - a chart of how many values have been entered day by day,
  so you can see whether collection is keeping pace.

## Reporting periods [#reporting-periods]

A **reporting period** names the period you are reporting - for example
"Reporting year 2025" - so the collection effort is scoped to one well-defined
window. You never create periods by hand: the app knows its **reporting interval**
(chosen when the app is created - calendar year, quarter, month, or a custom start
month and length) and derives the timeline of periods from it, into the past and
the future alike. Every period is there the moment the app exists.

A derived period starts as a plain calendar entry. It becomes a **record** the
moment you act on it - rename it, submit it for review, approve it, or run a
[round](./collection-rounds.mdx) against it - and keeps its name and window from then on.
Renaming works on any open period; the window itself always comes from the
interval and cannot be moved or resized.

**Changing the interval** takes effect from a month you choose, forward: periods
before that month keep their windows, and the timeline after it re-tiles at the
new rhythm. If the new boundary cuts an old period short, the shortened remainder
simply becomes its own (shorter) period. A change that would re-tile the window of
a period you have already acted on is refused with the period's name - reopen or
delete that period first, or pick a later start.

**Collection is never blocked by a missing period.** You can enter data for any
date at the datapoint's own collection cadence - past or future - without setting
anything up first. The only thing that locks a cell is a period that has been
**submitted for review or approved**: every bucket that touches such a window is
read-only until the period is reopened.

**Reporting periods are managed in the editor.** Click **Open editor**, then open
the **Reporting periods** tab (the calendar icon, the last of the editor's tabs).
The **Reporting interval** card at the top of the list shows the interval history
and, for admins and reporting managers, offers **Change interval from …** and removing the latest
change. Below it, the list shows every period with its status badge - a period
nobody has acted on is simply **open** - and the detail panel has two tabs:
**Configuration** (the label) and **Status & approval** (the sign-off flow
below). Deleting is offered on an acted-on period's row while it is still open and
not bound to a round; deleting it returns the window to a plain derived period, and the
values collected in that window stay.

The period you pick is shared across the app, so whichever one you select in the
header is the one every tab shows, and it rides in the page address, so a link you
share opens on the same period.

### Last year's figure, and carrying it forward [#last-years-figure-and-carrying-it-forward]

Ovidens puts last year's number where you need it: on the cell itself. Wherever you
enter a value, a small clock icon appears; hover it and you see that exact cell's
value in the preceding calendar years, most recent first, up to three years back.
Only years that actually hold a value are listed, and the icon does not appear at
all when there is no history. It reads the same for a single figure and for every
cell of a breakdown.

If a figure is unchanged from last year, you can **carry it forward**. Any empty
cell in an open reporting period offers a "carry forward from last year" action that
copies the previous window's value across and marks the cell as carried forward. The
marker keeps the provenance visible to reviewers, and the carried-forward value is
checked by the same rules as a value you type yourself. The action is not offered on
a period that has been approved and locked.

## Review and approve a reporting period [#sign-off]

When collection for a period is finished, you close it with **Approve & lock**: a locked,
versioned record of what you reported. Open the [Reporting periods](#reporting-periods)
tab in the editor, select the period, and use its **Status & approval** tab. It states
in one line what Approve & lock does (it freezes the period's data and publishes an
immutable version), shows the period's status with a plain-language explanation, and
lists what still blocks it.

* **Submit for review** (optional) hands the period from collection to review. While a
  period is in review its values are locked for everybody, administrators included, and
  only an administrator or a reporting manager of this app can reopen it - so what the
  reviewer reads is exactly what gets approved. Because it freezes the whole window,
  submitting is open to the people who collect or govern here and not to the whole
  workspace: an administrator, a reporting manager of this app, or somebody who holds an
  assignment on one of this app's open or finished
  [collection rounds](./collection-rounds.mdx). A member who is none of these has entered
  no figures here and is asked to have an administrator or reporting manager submit the
  period, or to be assigned to a round. You may submit while a collection round is still
  open - the panel says so, and says the figures may still change until it closes.
* **Approve & lock** freezes the period. TWO things gate it. First, no collection
  round bound to the period may still be **open**: approving freezes the data, so
  approving mid-collection would freeze the report while people are still answering.
  The panel names the rounds that are open and the confirm stays disabled until you
  close them. Second, readiness must be green: every applicable datapoint is filled
  and every blocking [consistency check](./checks.mdx) passes. Until then the button
  is disabled and the panel lists what still blocks it, by datapoint and by check
  message. Approving is for an administrator or a reporting manager of this app; a small
  team can approve straight from open without a separate review step.
* **If you were the last person to edit the period's figures, the approve dialog says so**
  before you confirm. You may still approve: the warning is there because an assurance
  review asks whether the person declaring the figures also entered them, and the activity
  log records on the approval whether the approver was the last editor. Approving through
  Vera or a connected AI records the same. If your organisation separates entering figures
  from approving them, ask somebody else to approve.
* **An outstanding change request never blocks approval.** If a reviewer has asked for
  a change on some answers, the panel says how many and says in words that it does not
  block: those figures are still editable and the period is still approvable. It is
  there so you decide knowingly, not so the platform decides for you. These three
  lines are shown only to the people who govern the app's collection - administrators and
  its reporting managers - so a collector submitting a period for review sees no warning
  about an open round; the hard block is on Approve & lock, which only they can do. A period whose rounds have
  since been deleted keeps its change requests but has no round left to count them
  off, so the line is absent there.
* Approving captures an immutable **version** of the whole app, so the report can
  always be reopened exactly as it was approved. In the approve dialog you may
  optionally expand **Add a declaration** to record who is declaring the report, their
  role, and, depending on your reporting framework, the basis and module option - each
  field explained inline. A declaration is not required and can be added on a later
  approval, so a one-click approval on a ready period is valid. The approved state shows
  who approved it and when, a link to that version, and the declaration when present.

An approved period is **locked**: its cells become read-only in the grid and a banner names
the status, so no one can quietly change a figure after it was declared. To make a change,
**unlock & reopen** the period. Reopening is for an administrator or a reporting manager of
this app, behind a confirmation, because
it unlocks the period for editing and sets aside the approval; the version you approved stays
in history, and approving again produces a fresh version and a fresh approval record.
Every submit, approval, and reopen is recorded in the audit log with who did it.

## Consistency checks [#consistency-checks]

Where a [validation rule](./indicators/input.mdx) guards a single value, a
**consistency check** guards a relationship between datapoints, for example that a
renewable and a non-renewable energy figure add up to the total. A failing check can
block **Approve & lock** for the period, so checks are what turn "all cells filled"
into "the report holds together". See [Consistency checks](./checks.mdx) for how to
write and read them.

## Contributors [#contributors]

**Contributors** is a tab of its own, beside Overview and Questionnaire. It lists
who has been entering data and how active they have been, for the same reporting
period. It is the quickest way to see who to thank, or to nudge, as a collection
deadline approaches.