In Collect v2023.1 and prior, forms that were finalized were accessible from "Edit Saved Form" and could be modified.
In Collect v2023.2 and v2023.3, finalized forms were editable from "Ready to send" by tapping on the filled form name. We introduced this as a grace period as we provide more functionality and documentation for users who would like to continue making edits to filled forms until a certain point in time. Read more in this thread.
In Collect v2024.1, finalized forms will no longer be editable.
You can read more about the updated user interface and the research that supports these updates in this thread. You can also try this out in beta.
Not being able to change finalized forms is a step backwards.
Is there anyone else who thinks the way I do? Recently I updated my odk-collect app to v2023.2.3. When saving a form I noticed that the end page has changed. In itself I have no problem that there are now two buttons “save as draft” and “Finish”. But what I find problematic is that from September 30, 2023 it will no longer be possible to open a completed form to change something before sending it to cloud storage.
We use ODK-collect to make vegetation recordings. It often happens that one comes to the conclusion that a previously noted plant species turns out to be a different species. In that case, the user has already set the form to “finalized”. But no problem – the form can still be opened and changes can be made. In the new workflow we now have to save all our forms as a “draft” first, then open them one by one when we want to send them, move to the last page, save them as “finalized”, and only then can they be sent .
Our forms are very heavy and slow to open, contain many pages with many calculations and therefore the described extra steps slow down the process.
The old workflow where marking a form as “finalized” really just meant it could be sent to the cloud was a really useful and easy to use feature. Drafts could not be sent, finalized forms could – and both could still be edited. It prevented that forms that were really in concept phase, could be accidentally sent to the cloud.
In my opinion, removing the possibility to modify finalized forms is a step backwards. A disappearance of a useful function, and I don't understand why this is done.
We know that this is a disruptive change for some workflows and are sorry to hear this has been the case for you. We do try to cause as little negative disruption as possible but it some cases like this we believe the benefits of the change will outweigh the negatives for most users.
We encourage anyone negatively impacted to share their workflows and forms as you have so that we can find other ways to improve things for them.
There were three major drivers: user confusion around whether or not finalization was final, inconsistent states when a submission was auto-sent and edited at the same time, and the need for a truly final form state to support the new entity concept which allows for sharing information between forms. Those three combined led us to the current solution. Again, we don't expect that it's perfect for everyone, but we do think that it solves many different problems that users were experiencing.
This change will come into effect in the upcoming Collect release. It is now in beta and we expect it to be released in the first or second week of February.
We have published a guide on designing what data collectors can do when they're ready to exit a form. We hope this will help anyone still needing to adapt to this change or designing new projects.
It includes some common workflows with example forms and setting combinations to address them. For example, here are screenshots from a form requiring supervisor review:
Ask the reviewer to type in a special code which they don't show to data collectors (use the Delete after send setting so data collectors can't view the code in sent forms).
I'm using a QR for this, I generated a set of UUIDs and encoded into QRs which i provided to my approvers to print and carry, and the question has constraints to match these values. It's instant to scan, and would have to be copied to bypass, so a bit faster to use and harder to get around than a password that's entered in non obfuscated text. A savvy user could always view the UUID and make their own QR, but if that happens i guess i could incorporate a transform.
I am a little sad to lose the ability to unfinalise, as my main review steps are not in field but remote and post upload, so a change, minor or major, requires rejection and recompletion vs unfinalising, editing, refinalising and uploading.
What a great idea! I've added that to the guide, thanks.
I'm having trouble understanding how the change affects you! What you've described sounds like a feature we've considered now and then but that doesn't currently exist -- it sounds like you're talking about on-device edits after submission. Can you please share some more details around your desired workflow?
You may also find some upcoming edits to the guide interesting. Specifically, I've split "edits are needed but it's not known ahead of time to which drafts" and "edits are needed to specific, known drafts". Most cases we've seen that are disrupted by this change fit into the first category. You can see the pending change on Github.
Yes, this is uncommon / undocumented (?), and I didn't originally have much call to use it, but with increased volume and application of ODK I do now.
It's the ability that did exist to unfinalise an uploaded record, make changes to it, then refinalise and upload, which would then update the submission in Central with the new/different content. This did allow a workflow where the enumerator could upload a record, someone remote to them could review the content, and if there were issues, communicate this to them so they could correct and reupload.
The alternate is to reject the record and redo it entirely, which wastes time on the unchanged elements being recompleted/recaptured, and potentially isn't even possible if accessibility or location has changed.
An ideal workflow for me (which is potentially something that will never be a feature for many reasons!) would allow two way sync, so the contents of a submission could be viewed by someone remote to the enumerator, and they could reject / revert / comment (mistake made, not enough detail, photos unclear...), so the draft and uploaded, or, considered to be final and uploaded, record could be returned to device for correction/addition post review. (If Enketo behaved identically and Central had more granular user roles this could be an alternate way to do edit/update)
Could you explain, how you did this?
We used a similar approach for supervision in the field, after finalisation, but before submission.
Another great IDK feature would be to have a mirror function to copy cases between enumerator and supervisor device. Such a copy could also enhance data security. A server-based supervisor work flow would not work for remote areas.
This is not something that has ever intentionally existed. Central is intended to reject a submission with an instanceID that matches an existing one and Collect treats the sent state as separate from finalized. If you believe that has been possible previously, it would be helpful to get more details on how.
Sorry, I meant to come back and clarify but I have been sidetracked.
No, I haven't actually done this, but I have a very strong memory of reading about this or discussing the ability to do it at the summit with someone. In the absence of evidence that it is actually possible, I retract my comment!
If your project is unsure how to adapt to this change, we recommend that you start by reading the guide on designing an end-of-form workflow.
