Collect: enable data collectors to make edits to finalized or sent forms already on their device

Based on user feedback, we are considering allowing data collectors to make edits to finalized or sent forms that are already on their device. This functionality would be off by default.

We discussed this topic on the April 3rd Insiders call. I'll share the takeaways and summary in a subsequent post.


Proposal

Provide additional support for workflows that want to enable data collectors to edit finalized or sent forms so they can capture new insights or fix mistakes. This is valuable for project managers because the data collector is in the field and has the context.

Example scenarios we've heard:

We collect demographic information on households. A data collector can mistakenly enter wrong date of birth or select the wrong gender and submit.

Enumerators are in a hurry during the day to reach their targets. Fixing any mistakes and resubmitting gives them time to review and check for any errors and as a project manager I prefer them to do it.

We currently imagine that the functionality would be accessed as a new option shown when tapping on a finalized or sent form in a form list:

In Central, these edits would be tracked exactly like a web-based edit: the change would appear in the submission activity feed and the submission's state would change to Edited.

We know there are workflows where making edits after the form is sent isn't appropriate, and project managers want to maintain control over the data quality process, which is why it would be off by default.

Longer-term, we may consider supporting a more structured experience where project managers on the server can "send back" submissions to specific data collectors with comments. For now, this idea is about editing submissions already on the device with data collectors having control of when that happens. Project managers would have to request edits through another channel (phone call, WhatsApp, etc).

In scope for a short-term feature :green_circle:

  • Editing finalized or sent forms (off by default)
  • Configured in form design
  • Collect users can make multiple resubmissions
  • Once an edit is made in Central, Collect users can’t edit
    • Data collector would have option to submit as new
  • When deleted in Collect, it can only be edited in Central

Out of scope :red_circle:

  • Edit of submissions collected by other device
    • Collect would work off local data only
  • No “Send back submission” with comments or issues
    • Workaround is to use other channels (e.g. whatsapp)
    • Can implement something like it with Entities

Why are we considering this functionality now?

Over the past year, user feedback has centered on giving data collectors more control over their submissions, as reviewing and editing submissions has been limited to Central users. In our user research about form finalization, we heard that people get confused about what state they are in, when they can edit, and when forms have been sent.

Now that finalization is truly final, we have clearer workflows and the foundation for new Entities functionality.

Depending on your needs, you could decide what option works best for your workflow:

Relationship to Entities: The big picture for Entities is supporting more workflows and improving data flow between “field” and “office”. This concept provides a different way to get at this goal and in particular supports folks who may not have longitudinal workflows but have more need for coordination between field and office.


Let us know what you think

What does your editing process look like? Does your workflow require editing or fixing mistakes after the data collector sends their forms? Even if you are not sure you would want to use this functionality, that is helpful feedback!

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.

4 Likes

I don't understand this, if the user has deleted the sent item, then there would be no way to edit/clone it as it's deleted. Should the Data collector would have option to submit as new option be under Once an edit is made in Central, Collect users can’t edit?

This would be an option that you could either edit finalised & unsent or finalised & sent, OR finalised & unsent only? Which brings back the functionality of editing post finalisation but restricts resubmission.

Yes! Quite often I find that a user starts one (or many :angry: ) drafts, and only then calls me to say 'oh the form is out of date/wrong/missing something/can we update-change this', and I have to tell them, yes, of course, however you have to trash all those drafts and start again once you sync to the new definition. So being able to apply the collected values to the most recent definition for drafts / sent forms would be very helpful

3 Likes

Yes I want to emphasize the urgency of this last point, feature of updating drafts to latest form definition without trashing already collected data.

2 Likes

You're right! That was a typo :sweat_smile:

This would be an option that you could either edit finalised & unsent or finalised & sent, OR finalised & unsent only? Which brings back the functionality of editing post finalisation but restricts resubmission.

Yes, that's correct. However, it’s not exactly the same functionality as before. Previously, editing a finalized form made it go back to the draft state. With this new concept, editing a finalized form that’s not yet sent would be the same as editing a finalized form that IS sent — it would be seen by the server as an edit.

For some workflows, there might still be value in making a distinction between finalized/unsent and finalized/sent for edit purposes, e.g., if data collectors get connectivity just at the very end of the day. This would essentially limit the time frame in which on-device edits can happen.

Yes! Quite often I find that a user starts one (or many :angry: ) drafts, and only then calls me to say 'oh the form is out of date/wrong/missing something/can we update-change this', and I have to tell them, yes, of course, however you have to trash all those drafts and start again once you sync to the new definition. So being able to apply the collected values to the most recent definition for drafts / sent forms would be very helpful

That makes a lot of sense and I could see how that would be so frustrating. And thanks @Stephen_K_ojwang for sharing your thoughts on this too. It's on our radar!

2 Likes