Using the Field Security Screen
Field security is configured per datastore, as a matrix of fields against security groups.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, and its architect-only Field Security button
Architect Panel → Security:
- Permissions — where the groups themselves come from
Finding it
Open the datastore from Architect Panel → Data → Datastores. The Field Security control appears there for architects, and opens the per-datastore matrix.
It is architect-only by design — field security is part of the application's design rather than day-to-day administration, and it should not be adjustable by whoever is on the service desk that afternoon.
Work group by group, not field by field
Take one group and decide its access to every field before moving to the next. Working the other way — one field across all groups — is how gaps appear, because it is easy to finish a field and lose track of which groups you have covered overall.
Group by group also matches how you will explain it afterwards: "what can the payroll team see" is the question people actually ask.
Start restrictive
Set the sensitive fields to no access for everybody, then grant back to the groups that need them. Starting permissive and removing access means every field you overlook stays open, and you will not notice — whereas an overlooked field in the restrictive direction produces a prompt complaint from somebody who needs it.
Errors that announce themselves are better than errors that do not.
Read-only is underused
The middle level fits a great many real cases: somebody who needs to see a salary to answer a question but must not change it, a caseworker who should read an assessment but not edit another team's work.
Reaching straight for no-access when read-only would do makes the system harder to work with for no additional protection.
Check the whole form afterwards
Removing a field changes the form for everybody in that group. Open a record as a member of each affected group and confirm it still makes sense — a form missing a field that other fields refer to can be more confusing than one showing something it should not.
Verify through the API as well
If integrations read this datastore, check what they now receive. A restriction that removes a field from an API response can break an integration silently — it will read an absent field as empty rather than failing, which is the worst way to find out.
Re-check after schema changes
Adding, renaming or removing fields all affect the matrix. Make reviewing it part of changing a datastore that uses field security, not an occasional audit.
Worked example
An administrator configures field security on an HR datastore. They set salary and bank details to no access for all groups, then grant payroll write access to both and line managers read-only on salary. They open a record as a test line manager, confirm the form reads sensibly with bank details absent, and check that the reporting integration — which never used those fields — is unaffected.
Recommendations
- Work group by group.
- Start with no access and grant back.
- Use read-only where it fits.
- Verify the form and the API before anybody relies on it.