Field keys

Every field has a key: a short name like asset_id or reading_end. The label is what people read on the form. The key is what everything else uses — scripts, exported column headings, spreadsheet columns, webhook payloads and document templates.

While a field is new, the key follows the label

Type “Asset ID” and the key becomes asset_id on its own. Once the form has been saved the key stops following, so that renaming a label never quietly breaks a script.

Renaming a key later is a migration, not an edit

Because the key is the durable identity of a field, changing it moves real data. When you rename one, FormDragon moves every stored answer from the old key to the new one and re-links any subform entries that pointed at it.

What it does not do is rewrite the places that mention the key by name — scripts, formulas, display columns and document templates. Those are listed for you instead, so you can update them deliberately.

Before you rename, check anything outside FormDragon that reads the key: a Google Sheet with a header row, a DragonDocs template, a webhook consumer, a Zap, a Power BI query. None of those can be updated from here.

Choosing a key

Lower case, words joined by underscores.
Describe the measurement, not the position on the form: reading_end, not field_7.
Keep it stable. A key that never changes is worth more than a key that reads perfectly.
Avoid names that collide with script functions — sum, value, rows, user, parent. A field with one of those keys still works, but scripts have to read it with value('sum') rather than the shorthand.