Fields Within the Model
Field permissions narrow access within a record somebody can already reach. The configuration screen and its three levels are covered under Field Security; this article is about how the layer fits the model.
Where to find it
Architect Panel → Security:
- Permissions — the per-field matrix and its levels
Architect Panel → Data:
- Datastores — where field security is enabled per datastore
It only narrows
A field grant cannot give somebody access to a datastore they do not have. If a group has no datastore permission, configuring their field access changes nothing — and this is the most common misdiagnosis in this area.
Check the layer above before investigating a field problem.
Opt-in per datastore
A datastore with no field permissions configured behaves normally: every field follows the datastore grant. Field security switches on for a datastore the moment you configure something on it.
That has a practical consequence worth knowing: the first restriction you add to a datastore changes how the whole datastore is evaluated, so test the entire form at that point rather than only the field you restricted.
When to reach for it
When one record genuinely mixes sensitivities — an employee record with a name and a salary, a case with a status and a medical note.
The alternative is splitting the datastore in two, and that is almost always worse: two records to keep in step, a relationship to maintain, and reporting that has to rejoin them. Field security keeps one record and narrows the view.
What it cannot do
- It cannot vary by record. Every record in the datastore is treated the same way — that is the row layer's job.
- It cannot grant more than the datastore layer allows.
- It cannot protect a value from somebody who legitimately has access to that field.
The first is the one people expect it to do. "This group can see the salary field, but only on their own team's records" is two layers, not one.
New fields need a decision
A field added to a datastore that uses field security has no explicit permission until you give it one. Set access when you add the field, particularly a sensitive one — the failure here is silent.
Combine with encryption for the sensitive ones
Field security controls who inside the system may see a value. Field encryption protects it if the database or a backup is obtained. They address different threats and the genuinely sensitive fields usually warrant both.
Worked example
An HR datastore restricts salary to read-only for line managers and hides bank details from them entirely. When a new "pension contribution" field is added six months later, it is given the same treatment as salary in the same change — because the team had made that part of their process for that datastore.
Recommendations
- Check datastore access first on any field problem.
- Use it instead of splitting a datastore.
- Set access on new fields as you add them.
- Pair field security with encryption on the sensitive ones.