Form Versioning

[lbaertlein1]

Problem: When a form is edited, it is overwritten in the system. There is no way to retrieve previous versions of a form. Data that had been submitted prior to editing is still stored in the database for the form, and can be retrieved by API. However, if a question has been removed from a form, it’s responses prior to the form’s editing are then not shown in the Campaign Data page. Similarly, the form metadata contains only the edited version of the form – so elements such as the label of deleted questions, or skip-logic or validation used in prior form versions cannot be retrieved.

Proposed Solution: Create a grouping and versioning system for forms, such that all past saved versions of a form are retrievable and each submission is linked to the version of the form that was used for the submission. This could be done by revising the campaignFormMeta table. Currently this table contains one row per form, containing that form’s metadata. When the metadata are edited, the data in the table are overwritten. The table could be revised to contain one row per saved version of a form. Every time a form is edited, a new row would be added to the campaignFormMeta table containing a new form UUID and a version UUID, along with the form metadata for that version. This would allow data to be retrievable both by form (across multiple versions), and by version. Submissions in the campaignformdata table would be linked to campaignFormMeta by form UUID but additional information would be available to associate forms of the same group type (e.g., ICM H2H Team Monitoring), called "group" here.

"Group" concept: Currently, forms in the campaignFormMeta have a UUID and several text fields such as Type and Category for different UI uses but which are not sufficient to differentiate the forms by the named "group" (e.g., ICM has many forms with different modalities). When a new version of forms will be created tracking at the group level will be needed. It is proposed that a group attribute could be added to campaignFormMeta to associate forms of the same kind in a way that is not current possible. The list of groups should have a GroupID and a GroupName. the groups would be

• PCA
• LQA
• FM Survey
  -

Version concept: Each form should have a version. This could be a user-configurable text field visible to Admins only. If an admin needs to update a form, they would edit the form, thereby creating a new version and assign it a new version value. The system should ensure that the version value is unique within the form group.

Active concept: The most recently created form within a group should be the form set to "active". There could be a binary field that designates active and non-active forms. Only one form within a group should be the active one.

Campaign data handling: By requiring form edits to create a new form, the scenario exists where a form may need an urgent edit during a campaign. This would result in 2 forms of the same group being associated with a campaign, the original which would have some data likely entered, and the updated with the revised structure. As forms are independent these would appear as two different forms in the campaign data form list. This issue does not propose to append or transform the form data within APMIS to have a single unified view of the 2 forms from the same group within the campaign under this scenario. e.g., if the LQAS form get edited within the campaign, the new form would be visible in the form selection dropdown along with the old and users would be expect to export and merge the data as needed outside of APMIS.

A caveat to editing a form within a campaign (highly discouraged) would be to ensure the users can differentiate the current version to use and the old one is removed if they synch and receive the new one.

Current Structure:

Proposed update:

The form "group" concept of the form would link the green form objects in the schematic below

Schematic of Form Classification with Added Version:

[bnygren]

Hi @DevSeg We added some more detail and clarification to the description to try to capture the discussion and represent the UI-visible version number concept. We can discuss further as a group to make sure it is feasible and clearly described. Thanks.