Adaptive Forms Authoring and Data Model Bindings
Authoring model
An Adaptive Form is built from a form container, panels, and field components, each backed by a field type and a data binding. The form model (schema, Form Data Model, or none) determines what bindings are legal. Key concepts: the form data model root, the bindRef/data reference syntax (for example customer/address/city), and how repeated panels map to arrays in the data.
Rules and scripts
Client-side logic uses the rule editor (visual rules) or custom functions; server-side validation and prefill use services and the submit action. Understand the difference between prefill (data in at render time), submit (data out), and draft/autosave. Know the submit actions (Forms Workflow, REST, FDM submit, PDF submit) and that the chosen submit action constrains the data format.
Traps
- Binding a field to a nonexistent schema node; validation may pass but data silently drops.
- Confusing panel repeatability with data array cardinality.
- Assuming client-side rules enforce security; they are bypassable, so server validation matters.
- Mixing fragment-based forms with different data models.
Worked rule of thumb
For any binding question, trace the path from form container root through panel to field and confirm the schema type at each step. A binding is valid only if every segment exists and the leaf type matches the field's expected type; repeated panels must sit on array nodes.