Reviewing and correcting submissions
Review and correct is how a team signs off on its data: each submission is approved, rejected or awaiting review, and a reviewer can correct an answer that is wrong, saying why. Nothing is ever lost: the submission stays exactly as the phone or web form sent it, and every decision and correction is kept with who made it, when and why.
Who can do what
- Reviewers, managers and owners of a workspace approve, reject and correct its submissions. With restricted workspaces on, it is the person's role in that workspace that counts.
- Owners and managers turn a form's review workflow on or off.
- Someone a workspace was shared with sees each submission's status, never the controls or the review history, and cannot correct anything. Data collectors never open the console.
Statuses and the review workflow
A submission nobody has reviewed counts as approved. Open a submission and use Review at the top of its page to approve it, reject it or set it back to awaiting review, with a comment if you like.
Each form has a review workflow setting, on its review page (Data, then Review on the form's row). With it on, every new submission arrives awaiting review. With it off (the default), new submissions arrive approved. Turning it on or off never changes a submission already received.
The review page lists a form's submissions by status: Awaiting review, Approved, Rejected or All, newest first, with how many corrections and open quality flags each has. Tick some (or the box at the top for the whole page) and Apply to the ticked submissions to approve, reject or set them awaiting review in one go, with one comment kept on each.
Correcting an answer
On a submission's page, each answer you may correct has Correct under it. Type the new answer and the reason, which is required, and Save correction. The answer is checked against the question: a whole number for an integer, one of the choice codes for a choice question, a date written YYYY-MM-DD, a latitude and longitude for a location. A blank clears the answer.
- A corrected answer is marked Corrected, with what it was, who corrected it and why.
- To undo a correction, correct the answer back to the original; the history keeps both steps.
- If someone else changed the submission's review while you had the page open, nothing is saved and you are asked to reload: no correction overwrites another one unseen.
Some answers cannot be corrected: photos, recordings and other files, text and audio audits, the device's and server's own fields (start and end time, the KEY), anything the form does not describe, and the fields a garbling scheme governs, since a garbled answer is randomised on purpose. An answer marked as identifying on the workspace's Privacy page can be corrected only by someone with identity access; anyone else sees it, its corrections and its history masked, as everywhere else.
Where corrected data goes
- Exports (the WIDE CSV, Excel, SPSS, Stata and its do-file, the long format and the Joripo layout) carry the corrected answers. Under Answers, choose As first submitted for the answers exactly as received.
- Exports include approved submissions only, so a rejected submission, or one awaiting review, is left out. Under Review status tick Awaiting review or Rejected to include them. Export current data in the Data Explorer exports exactly the rows on screen, every status.
- The Data Explorer, the submission page and Joripo Desktop show the corrected answers. The quality checks see them the next time they run (Run HFC checks).
- Joripo Desktop exports approved submissions only, like the server's default export: after its next sync, a rejected submission or one awaiting review is left out of its files, and its export report says how many.
- The Correction log (on the review page) lists every correction of a form: the KEY, when, who, the field, the answer before and after, and the reason.
- Attachments, text audits and audio audits are never changed, and a correction is never sent to phones.
Where it is kept
A submission's review is kept on the file server beside the submission itself, sealed like it when encryption at rest is on, so it survives rebuilding the database. Every decision and correction is also recorded in the organisation's audit log, without the answers.