Problem Statement: Survey123 currently requires all form elements to have a direct relationship with the underlying data structure. While this ensures tight integration, it imposes significant constraints on form design, particularly when:
Forms need to interact with multiple datasets.
UI elements, such as repeats or dynamic fields, must adhere to a predefined backend schema, even if the data collected is meant to be processed or transformed before storage.
Existing workflows must conform to rigid data structures, limiting innovation and customization for complex use cases.
This coupling creates inefficiencies in workflows, particularly when working with populated or legacy datasets. Users are forced to either redesign their datasets to accommodate forms or create multiple forms for similar workflows, leading to redundancy and increased maintenance.
Proposed Solution: Allow all Survey123 form elements to exist independently of the underlying data structure. This would:
Enable users to create forms that are entirely UI-focused, with no immediate link to a data source.
Use existing tools like calculated fields and JavaScript to map user inputs dynamically to one or more datasets during post-processing.
Allow form developers to define when and how data is submitted to datasets, enabling workflows to support multiple datasets seamlessly.
This approach could include:
Support for setting bind::esri::fieldType to "null" for any form element, including repeats, points, and images.
A mechanism to define data transformations and mappings at the form level, ensuring that inputs are processed appropriately before being sent to the backend.
The option to use predefined templates to either build datasets from forms or integrate forms into existing datasets.
Examples:
Single Workflow, Multiple Datasets: A utility company manages separate datasets for electric, water, and gas meters. A technician performing maintenance may need to record information relevant to all three datasets during a single visit. By decoupling the form from the backend, a single form can collect data dynamically and map it to the appropriate datasets without requiring duplicate forms or complex pre-configured relationships.
Dynamic Repeats Without Table Dependency: A survey form includes a repeat section to collect observations about site conditions. However, these observations are only relevant to the user’s analysis and do not need to be stored directly in the backend. Decoupling repeats from a mandatory table allows this functionality without requiring unnecessary database schema changes.
Customizable UI for Context-Specific Use Cases: A wildlife research team wants to use the same form to record data for different animal species but requires the form’s layout to change based on the species being studied. Decoupling the UI from the data structure allows developers to create context-aware forms that dynamically adjust without being constrained by a rigid backend schema.
Implementation Details:
Extend the functionality of bind::esri::fieldType to include all form elements, not just fields.
Allow users to define calculated fields or JavaScript functions that handle data mapping.
Extend the settings to be able to include multiple layer references.
Impact: This enhancement would:
Reduce the complexity of designing forms for organizations with multiple, disparate datasets.
Enable greater flexibility in UI design, empowering users to create forms that fit specific workflows without backend constraints.
Expand the potential use cases for Survey123, making it a more versatile tool for organizations with complex data collection needs.
By separating form design from data structure, Survey123 could provide users with unparalleled flexibility while maintaining compatibility with its existing features and tools.
