Per-Record Access

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

Where to find it

Architect Panel → Security:

Record Access Roles — the roles you can grant on a record — reader, contributor, owner and any you add

Architect Panel → Automation:

Teams — named groups you can grant to as a unit
Team Members — who is in each team

Grants themselves are made on the record, in the Assignment pane, rather than on an admin screen — the whole point is that they are per record.

Why record-level access exists

Group permissions are the right tool for a caseload an entire team handles. They are the wrong tool the moment a case involves a member of staff, an elected member, or a party personally known to one of your own people. In those situations the correct answer is not a team — it is a named list, decided case by case.

Record access sits alongside group permissions rather than replacing them. A user still needs the group right to reach the datastore at all; the record grant then decides which rows within it. Both must agree, and the more restrictive wins. That layering is what lets you open a datastore to a service while keeping individual cases closed.

The three kinds of grant

A grant names who, and what they may do.

A user — one named person. The usual grant.
A team — everyone currently in a team, resolved at the time of the check rather than copied. Add somebody to the team and they gain the case; remove them and they lose it, with no need to revisit the record.
A role — what the grant permits. Roles are defined once in Record Access Roles and reused, so "contributor" means the same thing on every case.

Team grants are worth understanding properly, because they are the difference between an access model you maintain in one place and one you maintain on thousands of records. If a case should be visible to "the safeguarding team", grant the team — not its current five members.

Setting it up

Open Security → Record Access Roles and define the roles you need. Start with three: read, contribute, own. Resist more until something genuinely does not fit.
Open Automation → Teams and create the teams that reflect how work is actually organised, then populate Team Members.
On a case, use the Assignment pane to grant access to the people and teams involved.

Worked example — a council complaints team

The complaints datastore is open to the Complaints security group, so any handler can pick up ordinary work. A complaint is then received about a named member of staff. The case is granted to the investigating officer and the HR team by name, and the group-level route is closed for that record. Handlers who would ordinarily see every complaint cannot see this one, and the fact that they cannot is itself recorded.

Worked example — a legal matter

A matter is granted to the fee earner as owner, the supervising partner as contributor, and the support team as readers. When the matter is transferred, the new fee earner is granted and the old one removed — and the file's history shows precisely when each of those happened, which is what a professional indemnity enquiry will ask for.

Removing access when involvement ends

Access should end when involvement ends. A case somebody handled two years ago that they can still open is an audit finding waiting to be written. Where cases are long-lived, review the grant list at each stage transition rather than only at closure — closure is the point people are least likely to do administrative tidying.

Recommendations

Grant teams, not individuals, wherever the work is genuinely a team's. Individual grants are for exceptions.
Grant the minimum role. A reviewer who must read a file does not need to reassign it.
Do not use record access as the primary model. If every record needs individual grants, the datastore is probably wrong — split it, or use row-level security on a field instead.
Review grants on sensitive datastores quarterly. The list only grows unless somebody prunes it.

What it gives you

The answer to the question an information governance team actually asks after an incident. Not "who could have seen this", which group permissions answer badly, but "who was given access, by whom, and when" — and, with the read log, "who actually opened it".