Record Access & Clearance

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.

Classification and Clearance

Classification labels a record by how sensitive it is. Clearance is what a user must hold to open a record at that level. Together they turn "please be careful with this one" into something the system enforces.

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.

Setting up levels

Keep the ladder short. Two or three levels that people understand beat six nobody can distinguish — and a classification scheme that requires a decision nobody is confident making produces records classified by guess.

Match the levels to language your organisation already uses. If your information governance policy names its tiers, use those names rather than inventing parallel ones.

Applying a classification

Classify at creation where the referral route tells you it is warranted, and allow it to be raised later. Raising a classification should be easy and lowering it should not — reducing sensitivity is a decision with consequences and deserves a deliberate step.

Clearance

Clearance is held against the user. A user without the matching clearance does not see the record in a list, not merely in a form — a case that appears in search results with its content hidden still leaks that the case exists, which for safeguarding is itself disclosure.

A caution

Classification is only as good as the discipline applying it. Audit a sample periodically: unclassified records that should have been classified are the common failure, and they are invisible unless somebody looks.

Break-Glass and Dual Authorisation

Two controls sit above clearance, for the cases where "no" is the right default but not an absolute.

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.

Break-glass

Break-glass lets someone open a record their clearance would normally refuse, on the understanding that the act is recorded and will be looked at. It exists because a rigid control gets circumvented: if an out-of-hours worker genuinely needs a file and the system says no, they will phone somebody who says yes, and there will be no record at all.

Break-glass keeps the access inside the system where it can be seen. Require a reason at the point of use — a reason typed under the knowledge it will be read is a meaningfully better record than a tick.

Reviewing it

Break-glass without review is just access. Give somebody the job of reading the log on a schedule, and make the volume small enough that reading it is realistic. A steady stream of break-glass events usually means the clearance model is wrong rather than that people are misbehaving.

Dual authorisation

Dual authorisation requires two people for an action, so no single person can take it alone. Use it sparingly and where the risk genuinely warrants it — opening a case involving a colleague, disposing of a record, releasing information externally.

The two people must genuinely be two people. If the second approver always approves without looking, the control is theatre. Fewer dual-authorisation points that are taken seriously beat many that are rubber-stamped.