Per-Record Access

Security groups answer "who can see cases". Per-record access answers a different and often more important question: who is on this case.

Where to find it

These features have no dedicated Architect Panel section of their own. They are configured through their datastores, opened from All Datastores, and most of what a caseworker sees appears on the record itself rather than on an admin screen.

Why record-level

Group permissions are the right tool for a caseload everyone in a team handles. They are the wrong tool when a case involves a member of staff, a councillor, or a party known to one of your own people — situations where the answer is not a team but a named list.

Record access grants a specific person or team rights to a specific record. It sits alongside group permissions rather than replacing them: a user needs the group right to reach the datastore at all, and the record grant decides which rows within it.

What to grant

Grants distinguish reading from contributing from administering the case. Give the minimum the role needs — a reviewer who must read a file does not need to be able to reassign it.

Removing access

Access should end when involvement ends. A case somebody handled two years ago that they can still open is a finding waiting to happen at audit. Where cases are long-lived, review the access list at each stage transition rather than only at closure.

What it gives you

The answer to the question an information governance team actually asks after an incident: not "who could have seen this" but "who did". Record access narrows the first, and the audit trail answers the second.