Implications of making changes to a Form Design

This article explains the implications of making changes to a form’s design in ActivityInfo. It is intended for Database Owners, especially those managing database that have already been deployed and are in active use.

Objective

After reading this article, you will be able to:

• Understand what changes you can and cannot make to a form design.
• Anticipate the impact of those changes on existing data, reports, and validation rules.
• Troubleshoot issues that may arise after modifying form fields.

What you can do

1. Update Field Labels

• Impact: No effect on previously entered data.
• Considerations: Updating a label may change how users interpret the field during data entry. Ensure that you communicate any label changes to data entry teams to avoid confusion.

2. Update Field Descriptions

• Impact: No effect on existing data.
• Considerations: Use clear descriptions to guide users. Updating descriptions is useful for clarifying instructions without affecting previously submitted records.

3. Update Field Codes

• Impact: Formulas and references using this field are automatically updated with the new code with an exception of calculated tables and calculated measures in reports.
• Considerations: Although ActivityInfo updates internal references automatically, double-check calculated fields and reports to confirm they still behave as expected.

4. Update Field Validation Rules

• Impact: Updating validation rules can cause previously added records to become invalid if they no longer meet the new validation criteria. Existing records won’t be affected, but it won’t be possible to edit a record until the validation problem is corrected.
• Next Steps: Review validation messages and correct invalid records to restore data validity.

5. Update Field Relevance Rules

• Impact: Similar to validation rules, relevance rule changes may render older records invalid or hide/show fields inconsistently. Existing records won’t be affected, but if you edit a record, you won’t be able to save changes until the validation problem is corrected.
• Next Steps: Review any records affected and make manual adjustments if required.

6. Update the label or order of options on Single/Multiple Selection Fields

• Impact: The updated option values will automatically be applied to all existing records.

• Considerations:

• Do not reorder existing options by changing their labels.

• If you rename an option, it will change in all existing records where that option was previously selected.

• Removing an option means that value will disappear from all records that used it.

7. Deleting an option from a Single or Multiple Selection field

• Impact: Any past records where that option was selected will show a blank for that field (because the stored option ID no longer matches any defined option). If the field is marked as required, the record will be flagged as invalid.
• Considerations: Before deleting options, consider cleaning up records that used the option.

8. Add New Fields

• Impact: Existing records are preserved, but new fields will be empty for those records.
• Considerations: If the new field is marked as Required, older records will become invalid until that field is populated. If you edit an existing record that is missing this field, you won’t be able to save changes until providing a value for the field.
• Recommendation: Consider leaving new fields optional if you are adding them mid-project, or plan for a data cleaning step.

9. Delete Existing Fields

• Impact:

• Deleting a field removes all data previously entered in that field.

• Any calculated fields, relevance rules, or validation rules that reference the deleted field will break and must be updated.

• Reports may be broken by the deleted field.

• Recovery: You can recover a deleted field (and its data) via the Audit Log.

• Recommendation: If you want to stop collecting new data but still retain historical values, you can keep the field and mark it as “Hidden from Entry/Table.”

What you cannot do

1. Update Field Type

• You cannot change the type of an existing field (for example, from “Text” to “Date”).

• Recommended Approach:

• Add a new field with the desired field type.

• Migrate historical data from the old field into the new one by exporting and importing records.

• Update any calculated fields, relevance rules, or validation rules that reference the old field so that they point to the new one instead.

Related considerations

1. Calculated Fields: Any change to field codes, dependencies, or linked forms may affect formulas. Always verify that calculated fields are still correct after editing form design. While ActivityInfo automatically updates field references in most formulas when the field codes are changed, calculated tables are not automatically updated and may break if the field code changes. Ensure that you review calculated tables manually after a field code changes.
2. Related Forms (Parent/Subform): Avoid renaming or removing fields used as linking keys. Doing so can break relationships between parent and subform records.
3. Reports and Dashboards: Any field deletion or changing the field code can affect formulas used in reports, charts, or dashboards using that field. Review and update any dependent reports after design changes.
4. Offline Data Collection: If users are collecting data in the field while working offline, form design changes are not applied until the next synchronization. This can affect pending and draft records.

Pending Records:

• Pending Records are submitted to the server as-is, even if the form has since been updated.
• They will appear as invalid in the interactive table view or when opened for editing if they no longer meet updated validation or relevance rules.
• The only situation that will block pending record submissions is a change in user permissions. If a user no longer has permission to submit a record, synchronization will fail.

Draft Records:

• Drafts records are stored locally on the device and are re-validated when the user synchronizes and downloads the latest form version.

• Drafts that no longer meet updated validation or relevance rules cannot be submitted until they are corrected.

• Users should review any invalid drafts and update them to match the latest version of the form.

Further reading on referential integrity and record validity.

Troubleshooting common issues