Changing a field's Input type wiped its answer and its settings
What you are seeing
Changing a field's Input type wiped its answer and its settings.
#Why it happens
By design. Switching type clears the stored value and drops settings that do not apply to the new type - options, multi-select, placeholder, number bounds and length limits.
#What to do
Decide the type before collecting answers. If you must change type on a live form, export the responses to CSV first.
#Settings involved
Setting | Where | What it does |
|---|---|---|
Advanced edition | Marketplace / licensing | Unlocks every input type beyond single-line text, and unlocks the Forms nav item in the Suite regardless of the flag. It does NOT unlock the Forms search panel - that is flag-only. |
#Limits that apply here
Limit | Value | What happens |
|---|---|---|
Standalone field autosave delay | 800 ms after the last change; "Saved" ti | Applies only to Input macros outside a Form container. |
#A few things that catch people out
The "Responded by" / "Responded at" stamp is applied to every form on the page at once, from the acting account - it is not per field or per form.
The CQL field name embeds the app hash, so it differs between the standalone app and the Suite. A saved CQL search does not survive the move.
#Related
Two fields' answers merged into one column in the responses table or CSV
Two fields on the same page share a Field ID. The index keys answers by Field ID, so the l
Large form's answers stopped appearing in the byline, the catalogue and property search - but they a
The page's forms exceeded the 28,000-character index cap. Multi-value answers were truncat
Everything else
The rest of this family.
Found it? Good.
