As mentioned above, we discussed this topic with the @Insiders on April 3rd. You can watch the recording here. Our goal on the call was to get feedback if we should move forward with allowing edits for finalized/sent forms given the limited scope, and configurability options.
Using Mural (digital whiteboard), we broke up into groups to discuss people’s workflow needs, how this feature might impact their work, and how it should be configured.
The majority of Insiders on the call think we should move forward with allowing edits with the limited scope and that edits should be configured in form design.
Themes from feedback
The value in allowing edits to finalized/sent forms
- Will increase data quality
- Reduce errors
- Will be more efficient for data collectors to make the edits
- Will save time for project managers
- Helpful to have data collectors edit when taking photos
Potential implications for edited finalized/sent forms
- It would create a second data point for data analysis
- Some workflows it’s important for the data to be sent straight away for tracking
- Allowing edits could make data analysis messy
- Making finalization final has been very helpful, and this change could make data collectors less careful if they can edit.
- Training will be required for newcomings which can be challenging
A few people were unsure
- Not applicable to their workflow
- Might not be helpful in the near term given the limitations
- Can already do something similar with Entities
Configure in form design
- Everyone preferred to have the project manager to have the control
- Better option if you only want specific forms edited
- Helpful for offline webforms
- A good place to start with a simple T/F parameter and then expand to time based, enumerator ID linked, External CSV for specific forms etc.
- Being able to control whether editing can happen from central
- Having data collectors configure in Collect would be another thing for them to deal with
Time limits and audit logs
- Edits for a certain duration, and then control goes back to Central users for edits afterwards
- Understanding when the edits happened would be helpful (e.g. submitted in the last 5 days)
- Edits after a certain amount of time, for reporting and data flow for dashboards
- Audit logs for edits will be helpful
Consider the number of edits allowed
- In some cases you wouldn’t want it to be edited multiple times
- Limiting the number of edits would be helpful
Supervisor workflows
- Being able to reject and send back with comments would be helpful eventually
- Ideal would be for server folks to release back submission for edit
- Specific settings that allow project managers to turn on/off and select specific people to have editing abilities, but this wouldn’t be in scope for the first version
Make a copy/clone and edit as new
- Some people don’t need edits to be on the same form, it could be a clone and folks in the office will reject the original one
- Introducing cloning would mean that there are repeats, so the option needs to be very clear so data collectors don’t do it by mistake
Q&A
Q: Could this be switched on and off as wanted?
A: It would be off by default. After the Insider call, we are leaning towards form-based configuration only. This means a form update would need to be received by a device for the setting to change.
Q: How will I know whether a data collector made device-based edits?
A: In Central, it would be just like a web-based edit: the status would change to “edited” and the activity feed would show the changes. We’re also starting to look at a Collect-wide system log kind of like the Central system log to keep track of actions taken like editing existing submissions (or changing settings, etc).
Q: What about finalized forms?
A: Could edit them, if the edit reaches the server before the original, server will reject. It would eventually succeed after the original is received.
Q: Why not introduce a setting that allows what was possible before: editing finalized submissions?
A: We’ve heard a lot of requests for editing sent submissions when a project’s review happens on the server. In those workflows, it’s preferable to get data submitted centrally as quickly as possible. Data consumers who review on the server may notice issues and require edits from the field. This is the primary need we want to address. We are considering making it possible to specify that only finalized but unsent forms can be edited. These edits would not be like draft edits – they would be visible from Central.
Q: Will configuration just be on/off?
A: Possible ideas we heard in the Insiders call beyond that are specifying a number of edits allowed or a time limit for edits (e.g. edits allowed for N hours/days after a submission is finalized). We are also considering making it possible to specify that only finalized forms (not sent ones) can be edited in this way.
Q: What happens with finalized forms that are still in enumerator's Collect app and have been updated by new versions in form definition?
A: By default, Collect uses the same form definition the submission was created with. We at some point will add functionality to reload with most recent form definition. If we use a form-based setting for this functionality, whether a given submission can be edited or not would be based on the form version it was created from.
Q: What about encryption?
A: We don’t currently have plans to make any kind of editing work with submission encryption.
Q: What if someone makes an edit from Central and then I try to make an on-device edit?
A: Server will reject. You’ll have the option of making a copy and sending as new.
Q: Can I/should I use this with entities?
A: Just like with Central, once a submission gets processed into an entity creation or update, it would be separated from that entity. That is, making an edit to the submission would not impact the corresponding entity. This could still be useful in an entity-centric workflow to edit non-entity data.