How Access Is Resolved

People belong to several groups and each may say something about the same thing. Understanding how that resolves is what makes access predictable.

Where to find it

Architect Panel → Security:

Permissions — the grants themselves
Record Access Roles — the row layer

Groups combine as a union

Somebody in several groups holds everything any of those groups grants. There is nothing to subtract, because there are no deny rules — so access only ever accumulates as memberships are added.

The practical consequence: adding somebody to a group to solve one problem can grant considerably more than intended. Look at what a group holds before adding people to it, not afterwards.

The layers evaluate in order

Datastore — if no group grants access, the answer is no and evaluation stops.
Row — where the datastore uses record-level access, is there a grant for this record?
Field — which fields on that record are visible and writable?

Because each layer can only narrow, a "no" at any point is final and nothing below can reverse it.

Working out what somebody can reach

To answer it properly, in order:

List the groups they are actually in — not the ones you expect.
Take the union of datastore grants across those groups.
For each datastore, check whether row-level access applies and what grants exist.
For each, check the field matrix for those groups.

This is genuinely harder on paper than it looks, which is the argument for the next point.

Test rather than reason

Keep a test account per major group and sign in as it. Five minutes of looking beats an hour of working it out from configuration screens, and it catches the group membership nobody remembered.

Never verify as an administrator — administrative accounts are generally exempt, so they see everything regardless of what you configured.

Removing access means removing every grant

Because access is a union, taking somebody out of one group leaves whatever their other groups grant. And a group removal does not remove per-record grants made to them individually.

When somebody changes role, check group memberships and individual record grants. The second is the one that gets missed.

More groups is not more secure

A large set of narrow groups produces heavy overlap, and people end up in six of them for reasons nobody recorded. The union is then very hard to predict.

A smaller set of well-defined groups, each with a clear purpose, gives access that can actually be reasoned about — which is what makes a review meaningful rather than performative.

Worked example

An access review picks ten staff at random and signs in as each with a test account mirroring their group memberships. Two turn out to reach a finance datastore through a group added for a project two years earlier. Nothing in the configuration looked wrong — it only surfaced by looking through their eyes.

Recommendations

Check what a group holds before adding anybody to it.
Test as a real member rather than reasoning from screens.
On a role change, review memberships and record grants.
Keep the group set small enough to reason about.