Field Security

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.

How Field Access Is Worked Out

People belong to several groups, and groups can each say something different about the same field. Understanding how that resolves saves a lot of confused investigation.

Where to find it

Architect Panel → Data:

• Datastores — the Field Security matrix per datastore

Architect Panel → Security:

• Permissions — the groups involved
• Blocked User Accounts — unrelated, but a common false lead on access problems

The datastore layer comes first

Field security narrows what somebody can already reach. If they have no access to the datastore, no field grant gives them any — and this is the explanation for most "the field permission is not working" reports.

Check the datastore permission before looking at anything in the field matrix.

An unconfigured datastore is unrestricted

Where no field permissions exist for a datastore, every field behaves normally according to the datastore-level grant. Field security is something you switch on for a datastore by configuring it, not a default posture.

The practical consequence: adding your first field restriction to a datastore is the moment its behaviour changes, and it is worth testing the whole form at that point rather than just the field you restricted.

New fields

A field added later has no explicit permission until you give it one. Whenever you add a field to a datastore that uses field security — particularly a sensitive one — set its access at the same time. It is the easiest thing in this area to forget, and the failure is silent.

Multiple groups

Somebody in several groups ends up with one level per field. Work out what your configuration gives them rather than assuming, and test with a real account — reasoning about group intersections on paper is reliably harder than it looks.

Test as a real user, never as an architect

Architects and administrators are frequently exempt from these restrictions, which makes an administrator's view useless for verification. A field you can see may be invisible to everybody it was configured for, and the only way to know is to look through an account that has the groups in question.

Keep a test account per major group. It is the single most useful thing you can do for this area.

Diagnosing a surprising result

In order:

1. Does the person have datastore-level access at all?
2. Which groups are they actually in?
3. What does the matrix say for those groups on that field?
4. Is the field new, and therefore unconfigured?
5. Are you testing as an exempt account?

The last two account for most surprises.

Write it down

The matrix records what, not why. A short note explaining the intent — which groups should see salary and on what basis — is what makes the configuration reviewable later, and it belongs with your other access documentation.

Worked example

A manager reports they cannot see a case's risk assessment. The datastore permission is fine and the matrix grants their group read access. The cause is that they had been added to a second, more restrictive group during a project and never removed. Removing them restores it — and the investigation took minutes because the group membership was checked second rather than last.

Recommendations

• Check datastore access first.
• Set access on new fields as you add them.
• Keep a test account per group and verify through it.
• Document the intent alongside the matrix.

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.