Validation workflow
Every submission passes through review before it counts towards the results.
How review works
Collected submissions arrive with the submitted status and join the validation queue, where an automated pass attaches a quality score and a list of findings. A reviewer then decides: approve, reject, or ask for a correction. Approving finalizes the submission — from that moment it counts in the results and appears in the Data Hub.
Submission states
| State | Meaning |
|---|---|
| Submitted | Received from a device or the web, not reviewed yet. |
| Reviewing | Opened for review, or a correction was requested and the submission is back with the collector. |
| Validated | Approved: the submission is final and counts in the results. |
| Rejected | Excluded from the results, with the reviewer's reason attached. |
Two rules keep the flow honest: a rejection or a request for correction always carries a written reason (the server refuses the decision without one), and a finalized submission — validated or rejected — is locked: the review action refuses a second decision on it.
Each decision is recorded with its reviewer and its comment: the queue shows the last reviewer on the line.
The validation queue
The queue is the Validation page, listed for the validator role and above. What it contains follows what you are responsible for: workspace owners, admins and managers see the whole workspace; project managers and validators see their projects — within their regional assignments and for the surveyors who report to them; a collector sees only their own submissions.
Filters narrow the list: free-text search (form or collector), status (Pending by default, or All / Approved / Rejected), findings by severity, and region. Opening a submission shows its answers next to the automated findings, with any media attached to it.
Decisions are made from the line: Approve, or Reject / Request edit with a mandatory comment. A selection can be decided at once, and a batch is applied in one transaction — either every selected submission is decided, or none is.
The automated checks
Each submission receives an automated pass that produces two things: a quality score and findings (missing value, out-of-range answer, duplicate, ...). Submissions with a low score — under 60 — are listed at the top of the queue, so the riskiest rows are seen first.
The pass can be re-run on a submission: the previous score and findings are cleared and the checks are queued again. The line shows the state of the run — never run, pending, running, done or failed.
Validation criteria
Each form can carry its own criteria — the rules the automated pass evaluates. A criterion targets one question: it must be filled, equal to or different from a value, above or below a threshold, between two bounds, in a list, matching a regular expression, or unique across submissions. Each carries a severity (low, medium, high), an action (flag, auto-reject, require correction) and can be limited to one region. Enabled criteria are evaluated on each pass and their hits appear as findings in the queue; form managers edit them from the form.
What counts in the Data Hub
The Data Hub dataset view only shows approved submissions, and its row count follows the same rule — a form with 500 collected submissions and 480 approved shows 480 rows. Submissions still under review, rejected submissions and deleted ones are not part of it, though they remain visible in the Submissions screen and in the queue.
Approving is the trigger: a submission that stays pending — or is rejected — never reaches the dataset.
Next steps
- Dashboards and exports — turn approved submissions into indicators, or export them.
- Roles and permissions — who can review, and who sees which regions.