Hidden and Special Hidden
Two types that hold a value on a record without displaying it on the form.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
They are not the same underneath
Worth knowing before choosing, because the difference is invisible on a form:
- Hidden stores a whole number and joins, so it can be reported through like any other reference.
- Special Hidden stores a much larger text value and does not join.
So a hidden reference you will report on wants the first; a larger stored payload wants the second.
What they are for
- A value set by the system rather than by the user — a source marker, a token, an internal reference.
- Something carried through a process without a person needing to see or change it.
- Context captured at creation — which form, which campaign, which route.
Hidden is not protected
The single most important point. Hidden means "not shown on this form". It does not mean the value cannot be seen, and it does not mean it cannot be changed.
The value is on the record. It appears in exports and in the API, it is visible to anything with access to the datastore, and it is in the audit trail.
If a value needs protecting, that is field security, which is enforced on the server — no-access fields are removed from the data before it is sent, and protected fields are stripped from every write. Hiding is presentation; field security is a control.
Never put a secret in one
It follows directly. A credential, a token or anything sensitive placed in a hidden field is not hidden from anybody who matters — it is merely absent from one screen.
Do not use it to smuggle data past validation
A tempting pattern: hide a field so its rules do not inconvenience anybody. It works and it produces records that pass validation while holding values nobody checked, which surfaces later as data nobody can explain.
Document what fills them
Hidden fields are invisible by definition, so nobody discovers what sets them by looking at a form. A hidden field with no note is a value somebody will eventually have to reverse-engineer.
Record what populates it and what it is for, in the datastore's own documentation.
Review them occasionally
They accumulate. A field added for a campaign three years ago is still being populated by something, and still appearing in every export. Because nobody sees them, nobody prunes them.
Worked example
A public form sets a hidden field recording which page the visitor arrived from, used for reporting on campaign effectiveness. It is documented in the datastore notes. The API token the form uses is not in a hidden field — it is not on the record at all, because a hidden field would have exposed it to every export.
Recommendations
- Never treat hidden as protected — use field security.
- Choose Hidden for references you will report on.
- Document what populates each one.
- Review them periodically — nobody sees them decay.