The Permissions Model

This subcategory describes the access model. The screens that configure each part have their own subcategories — Field Security and Record Access Roles — and are referenced where relevant.

Where to find it

Architect Panel → Security:

Permissions — named permissions and the groups holding them
Record Access Roles — per-record grants

Architect Panel → Data:

Datastores — the Permissions row action, where datastore access is granted

Grant-only

Access is granted, never denied. A group holds a list of what it is permitted to do, and anything not on that list is refused.

There is no deny mechanism because there is nothing for it to do — absence is already refusal. That sounds like a limitation and is mostly a simplification: with deny rules, "why can this person see this?" requires evaluating every rule that might apply and their precedence. Without them, the answer is a short list of grants.

The cost is that you cannot express "everybody except" in one step. You grant to those who should have it, which is more typing and considerably easier to review.

Three layers

Datastore — may this group work with this kind of record at all?
Field — which parts of those records may they see and change?
Row — which individual records may they reach?

The layers narrow; they never widen

This is the single most useful rule for reasoning about access. Each layer can only restrict what the layer above allowed.

A field grant does not give access to a datastore the group cannot reach. A record-level grant does not override a datastore permission. So when something is unexpectedly inaccessible, work downwards from the datastore — the fault is almost always at a higher layer than the one being investigated.

Permissions attach to groups

Never to individuals. A person's access is the union of what their groups grant, which is why adding somebody to a group can give more than intended, and why membership deserves as much review as the grants themselves.

Administrators are not a good test

Administrative accounts are generally exempt from these restrictions. Verifying a permission configuration while signed in as one proves nothing at all.

Keep a test account per major group and check through it. This is the most common reason a permission problem reaches production.

Diagnosing access

Which groups is the person actually in?
Does any of those groups have datastore access?
Is the field restricted for those groups?
Does the datastore use row-level access, and do they have a grant?
Are you testing as an exempt account?

Worked example

A caseworker cannot see a case they were told to handle. Datastore access is present; the field matrix is not involved; the datastore uses record access roles and no grant exists for them. They are added as a co-worker on that case, with a reason and an expiry. Four questions, answered in order, and no guessing.

Recommendations

Work downwards through the layers when diagnosing.
Grant to groups only.
Keep test accounts and never verify as an administrator.
Prefer more grants to fewer, broader ones — they are easier to review.