Field Security Overview
Datastore permissions decide whether somebody may work with a record. Field security decides whether they may see or change a particular field on it.
Where to find it
Architect Panel → Data:
- Datastores — the Field Security button on a datastore, for architects
Architect Panel → Security:
- Permissions — the groups field access is granted to
- Record Access Roles — row-level access, a different axis
The problem it solves
Records frequently mix information with different sensitivity. An employee record holds a name and a desk number that half the organisation may reasonably see, and a salary and a bank account that almost nobody should. A case record holds a status and an address alongside a medical note.
Without field security the only options are to give everybody the whole record or to split it in two — and splitting means a second datastore, a relationship to maintain, and a record whose two halves can drift apart.
Three levels
- No access — the field is not returned at all.
- Read-only — visible, not changeable.
- Writable — normal access.
Levels are granted per field, per security group.
Enforcement is server-side, on both paths
This is what makes it a security control rather than an interface convenience.
On read, fields at no-access are removed from the row before it is returned — the value is never sent to the browser, so it cannot be found in a page source, a developer tools panel or an API response.
On write, protected columns are stripped from every insert and update before they reach the database. A field that is read-only for somebody cannot be changed by them through any route, including a crafted request.
Both checks sit in the platform's own data layer, so they apply to the interface, the API and anything else built on it, without each having to remember.
Opt in per datastore
A datastore with no field permissions configured is unrestricted, and the checks cost nothing there. Apply field security to the datastores that need it rather than as a matter of routine.
It is a different axis from row access
Row-level access controls which records somebody reaches; field security controls which parts of the records they already reach. They compose: a caseworker may see their own team's cases (row) but not the financial assessment on them (field).
Keep it for genuinely sensitive fields
Restricting a field for tidiness produces forms with holes in them and users who cannot explain what they are looking at. Restrict what is sensitive; leave the rest.
Worked example
An HR datastore holds employment details, salary and bank account. Line managers get read-only access to salary and no access to bank details; the payroll group gets both, writable. One datastore, one record per employee, and the bank account is never sent to a line manager's browser at all.
Recommendations
- Use field security instead of splitting a datastore.
- Restrict only genuinely sensitive fields.
- Remember it applies to the API too — that is the point.
- Combine with row access when both axes matter.