ODK Central Form Release Checklist

An ODK form release is ready when the new version has passed workbook checks, Central draft testing, an offline device test, an export review, and a documented field-team cutover. Publish only after the release owner can identify the form version, test evidence, and recovery plan.

Use this checklist for a new form that is moving into production and for a change to a form that is already collecting data. For the detailed version rules, see the ODK Central form versioning guide.

1. Decide whether this is a new version

Start by writing down what changed and why. A label correction, a new constraint, a changed calculation, a new choice, and a new repeat can have different effects on data collection and analysis.

Create a new form version when the form definition changes. Keep the same form_id and update the version value in the settings sheet. Do not change a live form by deleting it and creating a replacement with a new identity.

Before editing, record:

• The current form ID and published version.
• The study period and field teams using the form.
• The questions, choices, calculations, or media that will change.
• Whether the export columns, repeat tables, or analysis code will change.
• The release owner, reviewer, planned cutover time, and recovery contact.

If the change alters the meaning of a response, have the research lead approve the wording and analysis impact before technical testing begins.

2. Freeze and preserve the current release

Keep a copy of the production XLSForm, media files, published form definition, and a recent export. Record the version in the study's release log before you upload the next draft.

The release log should answer three questions:

1. Which version was active before the change?
2. Which version is being tested and what is different?
3. Which version is approved for the next field period?

Preserve an export using the current production definition before removing or renaming fields. This gives the analysis team a stable reference if the new definition changes how historical records are represented.

3. Upload the draft and resolve warnings

Run the XLSForm validation checklist before uploading. Confirm the survey, choices, and settings sheets, names, expressions, media references, translations, and version value.

Upload the form to Central as a draft and read every conversion error and warning. Do not treat a successful upload as approval. A draft can still have a wrong skip path, missing media, confusing wording, or an export structure that does not fit the analysis plan.

Check the draft for:

• The expected form ID, title, and version.
• Correct question names, choice lists, calculations, and constraints.
• Attachments, translations, appearances, and audit settings.
• Entity List names and property definitions when the form uses Entities.
• Warnings that need a written decision before publication.

Draft submissions are temporary. Keep important debugging evidence outside the draft because replacing, abandoning, or publishing the draft can clear those test records.

4. Test the form like a field collector

Use the same Android device type, account permissions, network conditions, and media path that the field team will use. A browser preview is useful for a quick logic check, but it is not a substitute for a device test.

Complete one realistic test interview and cover the paths that are most likely to fail:

• Required questions and every important skip path.
• Constraints, calculations, repeats, and choice filters.
• Translations and media capture or playback.
• GPS, audit logging, identity, and timing when used by the study.
• Interrupted work, saved drafts, and reopening a form.
• Airplane mode, finalization, reconnection, and sending.
• The expected form version in the device's form list.

Use a dedicated testing App User or a separate test Project when the study needs collector training, multiple forms, Entity updates, or realistic submission workflows. The ODK testing guide explains when a draft is enough and when a separate test setup is safer.

5. Review the submission and export

After the test reaches Central, inspect the record before approving the release:

1. Confirm the record arrived in the expected project and form.
2. Check the form version, submitter, timestamps, and instance ID.
3. Inspect calculated values, repeats, media, and audit evidence.
4. Apply a review state or note if the study workflow requires one.
5. Export the test data and compare columns and repeat tables with the analysis plan.
6. Confirm attachments can be found and joined to the correct submission.

Use the ODK submission review checklist when the release includes export, review-state, repeat, or media changes. If the form creates or updates shared records, also test the ODK Entities and longitudinal workflow.

6. Run the release gate

The release owner should mark each item complete before publishing:

Gate	Evidence to retain
Form identity	Form ID, title, and new version
Workbook quality	Validation result and resolved warnings
Field workflow	Device test covering offline and send paths
Data quality	Practice submission reviewed in Central
Analysis impact	Export compared with the analysis plan
Access	App Users and Form Access checked
Operations	Cutover time and collector instructions
Recovery	Current export, source files, and named owner

If any gate is open, keep the form in draft or delay the cutover. A release that is technically publishable can still be operationally unsafe.

7. Publish and roll out the version

At the agreed cutover time:

1. Ask collectors to finish or send finalized interviews on the old version.
2. Publish the approved draft in Central.
3. Confirm the published version and access settings.
4. Tell collectors when to refresh or download the form.
5. Ask each device owner to confirm the new version and complete one practice record.
6. Resume production collection only after the device check passes.

Use the ODK Collect offline workflow checklist for the device-side download, offline, and send checks. If a script manages the release, keep publication behind an approval step. The ODK Central API automation guide covers the draft, warning, test, and publish sequence for automation.

8. Monitor the first production records

Review the first records from every field team or device group. Look for the expected form version, missing media, unexpected skips, failed constraints, send backlogs, and changes in export columns.

Keep the old source, release log, approval evidence, and pre-cutover export with the study files. If a serious issue appears, stop new collection or restrict access while the study owner decides the recovery path. Fix the source, test the next version, and publish a new controlled version rather than silently changing the live definition.

How SurveyLoopr can help

LooprAI can help draft or revise an XLSForm, while managed ODK hosting can provide the Central server layer. Your study team still owns the questionnaire, test evidence, version approval, access decisions, and analysis policy.

Deploy a managed ODK server

Build an XLSForm with AI