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:

Does the person have datastore-level access at all?
Which groups are they actually in?
What does the matrix say for those groups on that field?
Is the field new, and therefore unconfigured?
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.