Collection rounds

A collection round is how an app asks for its figures. Instead of asking the whole workspace for an app's figures, a round asks NAMED PEOPLE for the figures of the unit they are responsible for - a subsidiary, a site, a department - and lets an administrator or a reporting manager approve each answer, reject it, or send it back to the same person with a reason.

Four words carry the whole feature, and nothing else means the same thing:

Because the ROUND owns its period, its datapoints and its people, you can set next year's round up while this year's is still running, and change your mind about who answers it without touching this year's. The one thing a round does NOT choose is the dimension its units come from: the app has one and every round asks along it, and once a round of the app has left draft it can no longer be moved elsewhere. A round still in draft holds nothing - you can still change your mind while nobody has been asked anything yet.

Rounds are set up in the app's editor, in one section called Collection, and reviewed on the app's own Collection tab. They are ANSWERED somewhere else entirely: on Tasks, a top-level page outside any app.

Setting a round up, and reviewing it, is for administrators and reporting managers. A Reporting manager is a role an administrator gives on the whole workspace, on one space or on one app (see Members and roles): it runs rounds, reviews answers and approves reporting periods there, and nowhere else. The editor's Collection section shows the email address of everybody responsible for each unit, so only somebody who manages the app's rounds is offered it - and the app's Collection tab, which is where answers are judged, is theirs alone for the same reason. Answering is for everybody who is asked, and they need neither the editor nor the app: what they were asked for appears under Tasks (see Step 5).

Step 1: choose the app's reporting-unit dimension

A reporting unit is not a new list you type out. It is a dimension member: you pick which of the app's dimensions holds its reporting units, and its members become them. If you collect per site, the Site dimension is it; if you collect per subsidiary, that one is.

The app has one, and every round of it collects along that one. Open the editor, go to Structure -> Dimensions, open the dimension you want and turn on Reporting-unit dimension. Turning it on for another dimension moves it - a dimension list never shows two.

Two things follow, and the second is worth knowing before you start:

• The app has to be published for a round to leave draft, because collection runs against the published structure. Set the dimension, publish, then open the round.
• Once a round of this app is running or finished, the dimension can no longer be moved. Every answer and every review decision names one of its members, so re-pointing it would strand them. Setting it back to the dimension the published structure carries is still allowed, and that is the repair if a draft has drifted away from it. To collect along a different axis, return those rounds to draft - resetting their review decisions first - or use a separate app.

Step 2: define the round

Switch to Collection and add a round. It carries:

• a name and a technical id,
• an optional description - what this round asks for, and of whom,
• exactly one reporting period, which is the window it collects for, and
• the datapoints it asks for.

The app's reporting-unit dimension is shown here for reference; it is not something the round chooses.

Choosing the datapoints IS defining what the round asks. Three kinds of datapoint cannot be asked for, and each is listed greyed out with its own reason rather than hidden:

• one you cannot choose yet because the app has no reporting-unit dimension. Set that first - it decides what can be asked at all.
• one that is calculated rather than answered. The app works it out from other datapoints, so there is no answer for anybody to give. Change it to a collected data type on the Indicators page if you want it in a round.
• one that is not collected by the app's reporting-unit dimension. It has a single organisation-wide answer and so no unit to review it against. Assign that dimension to it on the Indicators page.

If a round already holds one of those - because the datapoint changed after you chose it - you can still untick it while the round is a draft.

While a round exists on a reporting period, that period cannot be deleted: deleting it would take the round and every verdict recorded on its answers with it. Delete the rounds first, or keep the period.

Step 3: say who is responsible

Switch to the round's People tab. It shows the members of the app's reporting-unit dimension, indented the way they are nested - a region above its sites. Only the units at the level the app collects at can be given people, and the tab says which level that is; the units above them are shown for orientation and are not selectable. Select a unit, then pick the people responsible for it. The picker searches by name and by address, and offers only people this unit does not already have.

Assigning somebody does not give them access to the app. It says which units they answer for; whether they may answer at all is their access to the app. A person sees the task and can answer only if they may edit the app's data - Contributor or wider, on the app, on its space or on the whole workspace. Somebody you assign without that sees no task for this round, cannot open it and can neither answer, comment, mark it done nor hand the period over for review. Give them access under Access first, or as well.

So that this never goes unnoticed, the round says so: on the People tab and on the Tasks list under Collection, a person who is assigned but may not edit the app's data carries a Cannot answer chip, and hovering it says what to give them. The chip disappears as soon as they hold that access.

Copy respondents from on the Definition tab takes another round's people onto this one in one go, skipping anybody it already holds, so setting next year's round up does not mean retyping forty addresses. It is offered while the round is a draft. The result names every kind of skip, so nothing is left behind silently:

• Somebody this round has withdrawn stays withdrawn - the copy never restores write access - so you can restore them under People if they should be asked again.
• A unit that is no longer one of the app's reporting units is left behind, which is what happens when the app's collection level has moved since the round you copied from.
• An address the workspace can no longer place is left behind: nobody here holds it any more, or two people do, or the invitation it was made from was taken up by somebody who has since left, or it expired before anybody accepted. The copy makes the same check the picker makes, and a person the workspace cannot place cannot be given a unit by a copy any more than by hand. If somebody should still answer for that unit, invite them or pick them under People.

You can pick a member of this workspace, or somebody you have invited who has not accepted yet - and the copy applies exactly the same rule. An open invitation is offered in the same list, marked Invited. If the person you need is neither, invite them on the Access page - the picker links to it - and pick them once the invitation exists. There is no free-text address field: you always pick a person the workspace already knows, so an address nobody here has cannot be made responsible for a unit.

Assigning an invited person works, and it starts granting when they accept. Until then the assignment is held under their address and grants nothing - they cannot sign in yet. The moment they accept the invitation and answer for the first time, the assignment becomes theirs by identity. If you CANCEL the invitation instead, the assignment stays on the unit, grants nothing, and shows as Not in workspace; remove it, or invite the person again.

Assigning a member names the PERSON rather than the text of their address, so the address is only a label from then on: if they change their email address they keep their units, and if their old address is later given to a new colleague, that colleague inherits nothing. Remove an assignment when somebody leaves.

Each address shows where it stands:

• Member - they are in this workspace and can sign in now.
• Invited - they have been invited and have not accepted yet.
• Not in workspace - nobody here holds this address. A row can only read this way if it was made before responsibility was assigned by picking a member, or if the person has since been removed from the workspace. Such a row grants nothing. Remove it, and - once the person is a member - pick them again.

If two members of the workspace happen to share one address, assigning either of them is refused and names the address, because the assignment is held under that address and it does not say which of them you mean. Give each of them their own address, then pick the one you meant.

An invitation that has already been accepted, whose address no current member uses any more, is refused too - the person may have left, or changed the address on their account. Invite them again, or pick a current member instead.

You can only assign somebody a REPORTING UNIT - an active member of the app's designated dimension, at the level the app collects at. The rail is what shows you which those are: anything else is drawn as structure and cannot be selected at all, so a parent above that level, a member below it, or a deactivated one is never something you can pick a person for and be refused afterwards. A figure for a region is not typed beside its sites, it is rolled up from them by the pipeline, so the person who answers is the person who holds a site. Somebody responsible for three sites is assigned all three.

A unit with nobody assigned is in no round. That is deliberate: a unit a round asks always has somebody to ask.

Removing somebody from a round that is already running WITHDRAWS them rather than erasing them. The round did ask them, and their answers and any verdict on those answers outlive the assignment - so the row stays on screen, struck through and marked Withdrawn, and they simply stop being able to answer and stop seeing the round. Put them back with the restore control beside the row, or by adding the same address again. On a round that is still a draft the same control removes the row outright, because a draft round has asked nobody.

Step 4: open it

A round has three states, and the buttons say what each move does.

Once a round leaves draft its definition is fixed - it is what every verdict was recorded against. A round that has run is ended by closing it, never by deleting it, so no verdict you recorded is ever destroyed. You can return an open round to draft only while no answer carries a verdict.

Two rounds may not ask the same question at the same time

Opening a round is refused when another round that is already open or closed asks for one of the same datapoints over an overlapping reporting period. The message names that round, the first datapoint they share and how many they share, and it names the way out: narrow this round's datapoint list while it is still a draft, or return the other round to draft. A round you are REOPENING can no longer be edited, so there only the second one is open to you.

The reason is that a figure has to have ONE round deciding who may answer it and whether the answer is frozen. Two rounds over one answer means two verdicts, and no way to say which is in force. Rounds over the same datapoints in DIFFERENT reporting periods are fine - that is the ordinary year-on-year case - and so are rounds over different datapoints in the same period.

Publish the app before a round leaves draft

You define a round against what you see in the editor. It is ANSWERED against the app's published structure - the same structure every figure is collected against. A round that is open or closed while those two disagree is one nobody can answer, so the move out of draft is refused, and the message says which case you are in:

• the app has no reporting-unit dimension at all - set one first (see Step 1),
• its reporting-unit dimension is not in the published structure,
• the draft designates a different reporting-unit dimension from the published one,
• a unit you assigned somebody to is not in the published structure yet, or
• a unit you assigned somebody to is in the published structure but is not one of the app's reporting units - it sits at another level, or it is at the collection level and has been deactivated. The message names the unit, the dimension and the level. Withdraw that person under People, give them the units at the collection level they really answer for, or make the unit active again. Somebody responsible for a unit ABOVE the collection level would answer for every unit beneath it, including ones nobody gave them, which is why this is refused rather than allowed through.

Set the draft's reporting-unit dimension back to the published one, or - while no round of the app is open or closed yet, and while the draft designates a dimension of its own - publish the app, and move the round again.

The check runs whenever a round leaves draft, and again whenever a closed round is reopened, because a closed round governs its answers exactly as an open one does. Closing a round that is already open is not checked: it is already collecting, so closing it starts nothing new, and being unable to STOP a round would be the worse answer. The buttons here take a draft round to Open and no further, so leaving draft means opening it; the rule is stated over the states rather than over that one button because the API and the AI tools can also take a draft round straight to Closed, and the same check covers that move.

While a round is open or closed, publishing or restoring a version that would move the app's reporting-unit dimension, or move a unit out from under the person responsible for it, is refused for the same reason: the answers and verdicts already recorded name those units. Adding a new unit is fine, and so is every other structure change. A running round does not freeze the app.

Deleting the app's reporting-unit dimension is refused while the app holds ANY round, a draft one included. Delete those rounds first, then the dimension - and a round that has left draft has to be returned to draft before it can be deleted at all, so the full sequence is reset its review decisions, return it to draft, delete it. (Moving the dimension needs less than that: returning the round to draft is enough on its own.) A dimension the app has not designated deletes as it always did.

Opening a round sends nobody an email. The people responsible for a unit see the round the next time they open the app, so tell them it is there the way you would tell them anything else.

Step 5: answer it

A respondent opens Tasks in the left-hand navigation. They never enter the app that asked, and they need no access to the editor: providing a figure is not a reason to be walked into somebody else's app. The Tasks entry appears only once somebody has actually been asked something, and it carries the number of open rounds.

The page is ONE row per task - one round, one person, however many reporting units that person holds. A site manager responsible for three plants sees ONE row and opens ONE questionnaire covering all three, rather than chasing three. Each row names the round, the app that asked, the due date, and how far along it is in CELLS - "6 of 8 cells filled" - so a person who has answered for one of their two sites reads as half done rather than as nearly finished. Opening a row opens the questionnaire for the whole task, with one column per unit on every question. The way back is the same page; nothing on the task leads into the app.

Nothing else about the questionnaire changes - it is the same guided form described in Answering a round - but it is now narrowed to the questions the round asks their own unit (see "Why a unit is asked some questions and not others" below) and to that unit's own figures.

The reporting period follows the round, because a round collects for exactly one, so there is no period picker on that screen at all.

A task appears when the round is OPENED, and not before. Putting somebody on a draft round tells them nothing; opening it is what asks them, and everybody on it gets their task at that moment. Closing the round does not take it away - the task stays readable so answers, verdicts and the discussion on them can still be read back - it only stops the answers being editable.

A round somebody has been withdrawn from stops appearing for them.

If a reviewer asks for a change, the reason is on the answer and you can reply to it in the discussion beside it - see Step 6.

Asking Vera, or a connected AI assistant, to fill a round in works the same way and is bounded the same way: it reaches exactly as far as you do and no further - your own units if you are a respondent, every unit if you manage the app's rounds. Assigning a respondent and recording a verdict are not things an assistant can do at all - the first would widen who may enter data, and the second records a named person's judgement.

Step 6: review the answers

An administrator or a reporting manager opens the same Collection tab. The table is your worklist: one row per round and unit, which you can search, sort by any column, page through and export like any other table in the app.

The search box matches the round name, the unit name and the responsible addresses, so on a large tree you can type a site name or a colleague's address and get straight to their row. Sorting a column is yours to do; until you do, the rounds sit newest first with each round's units in the app's reporting-unit dimension's own order.

Who is responsible for a unit TODAY is a different question from the chip: a Withdrawn unit has a chip and no address.

Talking about one answer

Every answer carries its own discussion - one thread per question per reporting unit, opened from the answer itself on the questionnaire and on the review screen. It is where a change request gets answered: the reviewer's reason arrives on the answer, and the person who holds the unit replies there rather than by mail, so what was asked and what was said back sit beside the figure they are about.

• Anybody who holds that unit can post, and so can whoever manages the app's rounds. Nobody else sees the thread.
• It is append-only. A message cannot be edited or deleted by anybody, which is what makes it usable as a record of what was agreed.
• It stays open when the answer does not. An approved answer and a closed round can both still be discussed - a frozen figure is exactly the kind you need to be able to ask about.
• Nothing is gated on it. A thread never blocks a sign-off, changes no verdict and locks no cell; it is the conversation, not a decision.

Why a unit is asked some questions and not others

You do not configure this and there is nothing to keep in step. Each datapoint is collected at one level of the app's reporting-unit dimension - some at Site, some at Region - and the rule follows from that:

A unit is asked a datapoint when at least one member of that datapoint's collection level sits at or beneath that unit.

Read against a Region -> Site tree:

A question a unit is not asked is simply not shown to that unit, and does not count against its completeness: a unit asked 1 of 2 questions reaches 100% by answering that one - and the worklist's Answered column counts against the same asked set, so its denominator is what the unit can actually answer. A unit asked none of them still appears in the worklist, reading a muted 0 of M questions with the reason on the row beneath it, in place of the proportion bar - most often because its part of the tree has no member at the level the round collects at. Add the missing units, or collect the datapoint at a level the unit reaches, and the questions appear.

Deactivating a member takes it out of collection, so a region whose only site is deactivated stops being asked that site-level question.

Open a unit and you land on the same questionnaire that person filled in - the same questions in the same order, each with its guidance, its unit, its own grid and the figures they entered. There is no separate list of values to judge, because judging a flattened list is judging something other than what was answered.

While you review, the questionnaire is read-only. That is deliberate: correcting a figure and then approving your own correction under somebody else's name is not a review. If a figure really has to be corrected, leave review and edit it as you normally would.

Tick any number of answers and give one verdict:

There are two verdicts and no third one for "not acceptable": saying so while freezing the figure would leave a number the workspace had refused sitting in the report with nobody able to correct it. Request changes says the same thing, carries the reason, and leaves the answer open - so the round ends in a corrected figure or an honest gap.

A request for a change must carry a reason. It is not a note to yourself: the person who answered reads it beside the question they have to fix.

The verdict applies to every answer you ticked, in one go, and each answer then carries its verdict beside the question. For the person who answered, an approved answer is read-only under a chip naming who judged it and when, and one you sent back is editable again under your reason.

Only an administrator or a reporting manager of the app can record a verdict. Somebody else opening a review link simply gets their own questionnaire, with their own answers to fill in.

Where to read who approved what

The verdict shown on an answer is the one in force now. If you need the record - who approved a figure, when, and whether anyone reopened it first - open the Audit Analytics app from your apps list and go to its Indicator Data Changes tab. Under the table of value changes there is a second table, Answer Review Decisions.

It has one row per answer a verdict named, so a reviewer who approved a unit's five answers in one press leaves five rows, all sharing one audit id. Each row says the reporting period, the reporting unit, the datapoint, the verdict, and who decided it - under the name that person had at the time, not the name they use today. Reopening a verdict is recorded like any other decision, so filtering the table to one unit and one datapoint reads as that answer's whole history, newest first. The link on a row opens the app's Data tab, where the judged figures live.

Two things it deliberately does not show. The reason you gave for a rejection or a change request is not in it - a reason is written to the person who answered, and it stays beside the question they read it on. And nothing here is ever recorded against an assistant: recording a verdict is something only a person can do, so the AI column is always empty.

The Audit Analytics app is visible to workspace administrators only. If your workspace does not have it yet, an administrator can create it from the apps list.

Reading verdicts with SQL

Verdicts are data, not only chips on a screen, and two tables carry them for anything that speaks SQL.

Inside the app, the pipeline carries a Cell reviews table: one row per collected figure with the verdict currently in force over it - approved, changes requested, or none - plus the reason, who decided, when, and the reporting period it belongs to. A verdict matches the figure's OWN reporting unit exactly, with no walk up or down the tree, and covers every other breakdown of that question inside the period - exactly as the questionnaire shows it. It is always current, and it exists on every indicator app whether or not a round is running.

In your workspace's data lake, the same verdicts are mirrored to a table named ireview_app<id> beside the app's own figures, refreshed within about five minutes of a decision - so a BI tool or an export reading the lake can join "what was reported" to "what was approved" without touching the app at all. The mirror is a copy for reading: what a verdict PERMITS is always decided from the platform's own records, never from the lake.

Measuring round progress

Progress is data too. Every indicator app's pipeline carries a Round progress table: one row per round, reporting unit and question, saying whether the unit was asked it, whether at least one figure inside the round's reporting period answers it, how many cells that answer holds, and the verdict recorded on it - beside the round's name, status and reporting period and the unit's respondent counts. A unit that is asked nothing still appears, as a single row with no question, so nobody drops off a dashboard. It is always current, it exists on every indicator app, and an app running no round simply reads an empty table.

Three companion tables carry the definitions it is joined from - the rounds, the units each round covers, and the questions each unit is asked - so your own SQL can start from either end.

To chart it in an analytics app, add an Indicator data node to that app's pipeline and set its Content to Round progress: the node imports the whole progress table from the indicator app you pick, and a run snapshots it exactly like any other data - re-run to refresh. Narrow or reshape it with an ordinary SQL step, then put a table or chart on the Visualisation: "Hamburg has answered 12 of 15" is a filter and a count away.

Progress is counts, deliberately: none of these tables carries a respondent's or a reviewer's name or address. Who is responsible stays on the surfaces of the people who manage the rounds, and who decided stays on the review record.

What a round does and does not keep private

Worth being exact about, because it is easy to assume more.

• Writing is scoped. While a round is open, a respondent can enter figures only for their own units, and a workspace member with no assignment cannot enter any of that app's collected figures at all.
• The views that list the figures cell by cell are scoped the same way: the questionnaire, the app's own Data tab and the editor's data grid. On an app running a round, somebody who does not manage its rounds sees their own units' figures there and nobody else's - and the Data tab SAYS so rather than showing an empty grid, naming the units it is showing you, or explaining that you are responsible for none, or that the datapoint you picked has one organisation-wide answer that is not scoped to a unit at all. Reading a past version's pinned snapshot is not scoped.
• Totals and roll-ups stay open. Anyone who can open the app still sees the overview, the completeness views, the activity feed and every total and roll-up, exactly as they could before you ran a round - including figures that add up units they are not responsible for.
• Cell-by-cell figures do not. Wherever the app names a single cell rather than a total - last year's value behind a question, the cells a validation rule or a consistency check flagged, with the numbers that made them fail, and the cells a rule marked not applicable - somebody who does not manage the app's rounds sees only their own units' cells. The counts beside those lists stay whole, so a reader can still tell that more exist than they are being shown.

A round decides who is ASKED and who may WRITE, and it keeps one unit's cell-by-cell figures from another. It does not hide the app's totals from the rest of the workspace.