As you’ve identified, although Incomplete Forms are useful for circumstances where a form entry needs to be stopped temporarily, there are a few structural limitations to them that make them dangerous for long term usage
- They are not synced with CommCareHQ and are only ever stored locally
- **Consequence: **Even if syncing regularly with the server, a loss of access to the mobile device (say it is lost or destroyed) will result in the entered data being unavailable.
- They do not “Snapshot” the state of the phones databases (casedb, lookup tables, etc), but instead just load those databases in their current form when the form is resumed
- **Consequence: **If a form is saved as incomplete, then resumed after data the form relies on, the form will have undefined/unpredictable behavior
Example: A followup form for Mary is started and saved incomplete. After, a Death form is filled out, and Mary’s case is closed and removed from device. Resuming the followup form results in an error.
- CommCare doesn’t store the “original” version of the app a form may have been started with when the app is Updated to a newer version
- **Consequence: **Changes to the structure of the form’s data, or changes to the assets relied upon by the form (like the availability of images or audio), can make forms unresumable
We recommend that Incomplete Forms never be used as part of a predicted workflow, but rather as a tool for end-users on the ground who need to temporarily save work. If it’s expected that, say, a visit needs to be completed 2 weeks after the first visit, we’d build that interaction with two different forms and a case that stores any needed intermediate state.