Rounds, progress and updates from data

When a case is done

A case is completed for a form on the server, when an interview that names it arrives. The phone writes the case and the round into the submission; for ODK Collect, web forms and older phones, the server reads the form's caseid field and takes the form's current round. Sending the same interview again changes nothing. A draft or an opened form never completes anything.

Progress

Progress on the Cases page shows, for each case form in its current round: total, pending, in progress, completed (with the share) and needs review. Each count filters the case table. Each case can be Released (an in-progress claim dropped) or Reopened (a completed case becomes due again; its interview stays stored).

Rounds

A panel interviews every case again in each wave. Start the next round for every form at once (typed to confirm, with an optional name such as "Round 2: midline") makes every case due again for every case form. An interview done offline in round 1 still counts for round 1 if it arrives after round 2 has started. Each form's past rounds are listed, and Round N (.csv) downloads each case's state in that round: pending, in progress, completed by whom and when, closed, and any check still open.

The duplicate-ID quality check counts a household again only within one round, so a panel's next round is not reported as duplicates.

Giving cases to someone

Tick cases and Give them to a person or a team: this sets their users. A table counts each person's cases, pending, in progress and completed, for the form chosen. The warnings about names that reach nobody apply here too.

Needs review

Duplicates (a case and round completed already by another interview) and interviews naming an ID that is not on the list are listed under Needs review, each with a link to the submission. Use this one makes that interview complete the case instead; Keep the earlier one or Mark reviewed closes the question.

Updating cases from submitted data

Under Advanced: update case details from submitted data, each deployed form has its own mapping:

• Case column ← form field rows, for example status ← visit_status. A column not in the list yet is added.
• Field holding the case's ID: by default the form's caseid field, whatever it is called.
• Add new cases from this form, for a listing form that finds new households: a submission whose case ID is not on the list then adds a case. Map the column id to the field that holds the new ID, and choose the forms a new case opens.

When a submission arrives, only the columns whose value differs are changed, and a blank answer leaves its column as it was. A submission sent again changes nothing. A failure while updating the case list never rejects or loses the submission. Every change is recorded with each column's old and new value, the form and the submission's KEY.

The same person twice

Panels meet respondents interviewed twice in a round: by two enumerators, or under a second ID by someone hiding the first for the incentive. The same person twice on the Cases page looks for this:

• Who someone is. The columns and questions that hold the phone number, the national ID, the name, a parent's or spouse's name and the village are guessed from their names and labels (English and Bangla) and can be changed. Phone numbers are compared by their last ten digits; names without honorifics; a name is "similar" from 86% alike (adjustable), and only with the same village or a similar parent's or spouse's name.
• When an interview arrives it is compared with every other listed case and every interview already done in the round. The same phone or ID, or a similar name in the same village, is flagged as Possibly the same person as P002; another phone and another name than the case's own listing is flagged as Not the listed person?. The interview is stored either way, and a reviewer decides: the same person and the case is reopened, the same person and nothing changes, or different people.
• Two listed IDs for one person are shown as pairs: different people, or one closed as a copy of the other (phones then stop offering it, and it is not counted as pending).

With the phone column known, the page also offers form rows that look the respondent's phone up in the case list during the interview and ask the enumerator to confirm before going on.

Not built: blocking a second interview on the phone before it starts (the phone would need the whole round's identities offline). Today the form rows warn during the interview, and the server flags the interview when it arrives.