ODK Central Form Versioning Guide
ODK Central form versioning lets you test a draft, publish a new definition, and keep previous submissions in the project. The safe process is to change the form version, test the new workflow on a device, and tell the field team when to download the update.
This guide focuses on the form lifecycle in Central. For the wider server workflow, see ODK Central Basics.
For a release-owner checklist covering draft testing, exports, device rollout, and the first production records, see the ODK Central form release checklist.
What happens when you upload an ODK form?
Central stores a draft form definition until you publish it. On a new form, test submissions made against the draft are temporary. If you replace, abandon, or publish that draft, those test submissions are cleared.
Test the form before publishing it to a live field team. Check constraints, relevant expressions, calculations, translations, repeats, media, audit settings, and the export shape. The XLSForm common errors guide is useful when Central rejects the upload.
How do you publish a new form version?
When the draft is ready, publish it from the form's Central workflow. If the form definition changed, update the form's version value so ODK Collect can recognize the new version.
Use this sequence:
- Copy the current production XLSForm and record its version.
- Make the smallest required change.
- Update the form version in the settings sheet.
- Upload the new definition as a draft.
- Test the draft on the same device type used in the field.
- Check media, translations, logic, audit settings, and exports.
- Publish the draft after the pilot passes.
- Tell enumerators when to download the new version.
The official ODK Central forms documentation explains the draft and publish workflow in detail.
Are previous ODK submissions lost when a new version is published?
Publishing a new version does not remove previous submissions. They remain in Central and can be exported with the new data.
The export definition can still change. By default, Central uses the current form definition for exports, so a field removed from the current definition may not appear in the default export even though earlier submissions contained it. When historical fields matter, review the export options and retain the original form definitions with the project data.
Read the official ODK submission export documentation before changing fields in a live study.
What should you test before changing a live form?
Use a device and account that match field conditions as closely as possible:
- Download the draft or published test version.
- Complete the form offline.
- Test every important skip path and constraint.
- Capture and submit media if the form uses attachments.
- Confirm translations and choice filters.
- Verify audit logging when the study relies on timing, GPS, identity, or answer changes.
- Reconnect, send the submission, and inspect the server record.
- Export the test data and compare its columns with the analysis plan.
If the change affects the questionnaire's meaning, pilot it with the research lead before updating the full field team. A technically valid form can still create a measurement problem if the question wording, response options, or skip path changes unexpectedly.
How should you coordinate a form update with enumerators?
Choose a cutover time and document the version that is allowed in the field. Ask enumerators to finish or send finalized interviews, download the new form, and complete one practice record before resuming production work.
Do not delete and recreate a live form to force an update. Keep the same form identity so Central can retain the submission history and the team can distinguish form versions in its records.
For a larger platform change, use the KoboToolbox migration guide or SurveyCTO migration guide to plan a parallel pilot and cutover.
Do not publish a live form update until the new version has passed an offline device test and the team has a cutover plan. Publishing changes the form available to users with access.
How does LooprAI fit into form versioning?
LooprAI can help draft or revise an XLSForm, but the research team still needs to review the workbook, test it in Central, and decide whether the change is valid for the study. Use the build XLSForms with AI guide for the authoring workflow, then follow the versioning checklist above before publishing.
Build or update an XLSFormContinue with ODK Central basics
Frequently Asked Questions
How do I update an ODK Central form?
Update the XLSForm, change its version, upload it as a draft, test it on a field device, check exports and media, and publish it after the pilot passes. Tell enumerators when to download the new version.
Do ODK Central form updates delete old submissions?
No. Previous submissions remain in Central when a new form version is published. However, the default export uses the current form definition, so fields removed from the current definition may need special export options to appear.
Why must the ODK form version change?
ODK Collect uses the form version to recognize that a new definition is available. If the definition changes but the version does not, Central cannot publish it as a new version without changing the version value.
Are ODK Central draft submissions kept?
Draft test submissions are temporary. Replacing, abandoning, or publishing the draft clears those test submissions, so keep any test records needed for debugging outside the final project data.
Should I delete and recreate a form to update it?
No. Update the existing form and publish a new version. Deleting and recreating a live form can break the form identity, disrupt field devices, and make submission history harder to manage.
No Credit Card Required
Build the form first. Add hosting when you need it.
Start free with LooprAI, then deploy a managed ODK Central server or run DataSnap checks when your project is ready.
Automation handles the mechanical work.
Researchers decide what the evidence means.