Record Access & Clearance

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

1. 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.
2. Open Automation → Teams and create the teams that reflect how work is actually organised, then populate Team Members.
3. 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".

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 rather than something staff are asked to remember.

Where to find it

Architect Panel → Security:

• Classification & Clearance — the console — schemes, levels and who holds what, in one place
• Classification Schemes — a named ladder of sensitivity
• Classification Levels — the rungs within a scheme
• User Clearance — which level each user is cleared to

Schemes and levels

A scheme is a named ladder — you might have one for information security and another for safeguarding sensitivity, because they are different judgements about different risks. A level is a rung within a scheme, and levels are ordered, so clearance to a level implies clearance to everything below it.

Most organisations need exactly one scheme. Create a second only when you genuinely have two independent axes of sensitivity, because every additional scheme multiplies the decisions a person makes when they create a record.

Keep the ladder short

Two or three levels that people understand beat six nobody can distinguish. A classification scheme that requires a judgement staff are not confident making produces records classified by guess, and a guessed classification is worse than none — it looks like a control while providing nothing.

Use the language your organisation already uses. If your information governance policy names its tiers, use those names rather than inventing parallel ones that then have to be mentally translated.

How clearance is checked

Clearance is held against the user, in User Clearance. When a user without the matching clearance encounters a classified record, the record does not appear in lists, searches or counts — not merely in the form.

That distinction matters more than it sounds. A case appearing in a search result with its content hidden still discloses that the case exists, and for safeguarding, family law or HR investigations the existence of a case is frequently the sensitive fact. Hiding the content while leaking the row is a control that fails at exactly the point it is needed.

Setting it up

1. Open Security → Classification & Clearance.
2. Create a scheme, then its levels in ascending order of sensitivity.
3. Grant clearance to the users who need it. Start narrow — it is far easier to add a person than to explain why fifty people were cleared to a level they never needed.
4. Decide which datastores participate, and whether an unclassified record is open or closed by default. Closed-by-default is safer and more annoying; pick deliberately rather than by accident.

Worked example — children's services

A single scheme with three levels: Standard, Restricted, Highly Restricted. Most casework is Standard. A case involving a child known to a member of staff is Restricted. A case subject to a court order restricting disclosure is Highly Restricted, and clearance to that level is held by four people. When an inspector asks how access to sensitive cases is controlled, the answer is a screen rather than a policy document.

Applying a classification

Classify at creation where the referral route already tells you it is warranted, and allow it to be raised later by anyone handling the case. Raising should be easy; lowering should not. Reducing sensitivity has consequences and deserves a deliberate step and a reason — ideally dual authorisation.

Recommendations

• Audit a sample periodically. Unclassified records that should have been classified are the common failure, and they are invisible unless somebody looks for them.
• Do not classify everything. If most records are Restricted, the level means nothing and staff will treat it as noise.
• Train on the boundary cases, not the obvious ones. Nobody struggles with the extremes.
• Pair with break-glass. A control with no emergency route gets circumvented outside the system, where you cannot see it.

Break-Glass and Dual Authorisation

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

Where to find it

Architect Panel → Security:

• Classification & Clearance — where break-glass is enabled and its events reviewed
• Dual Authorisation — which actions require two people

Architect Panel → Activity:

• Record Read Log — who opened what, including every break-glass access

Break-glass

Break-glass lets somebody open a record their clearance would normally refuse, on the explicit understanding that the act is recorded and will be read.

It exists because a rigid control gets circumvented. If an out-of-hours social worker genuinely needs a file and the system says no, they will telephone somebody who says yes, and there will be no record at all — not of the access, not of the reason, not of who authorised it. The information has been disclosed either way; the only question is whether your system knows.

Break-glass keeps that access inside the system where it can be seen. Require a reason at the point of use. A reason typed in the knowledge that a named person will read it is a meaningfully better record than a tickbox, and it is also a mild deterrent to casual curiosity.

Reviewing break-glass

Break-glass without review is just access with extra steps. Give somebody the explicit job of reading the log on a schedule, and keep the volume low enough that reading it is realistic.

A steady stream of break-glass events almost always means the clearance model is wrong rather than that people are misbehaving — the level is set too high, or too few people are cleared. Treat a rising trend as a design signal, not a discipline problem.

Dual authorisation

Dual authorisation requires two people for an action, so no single person can take it alone. Configure which actions require it in Security → Dual Authorisation.

Use it sparingly and where the risk genuinely warrants it:

• Opening a case involving a colleague or an elected member.
• Lowering a classification.
• Disposing of records ahead of schedule.
• Releasing information externally where the release is itself consequential.
• Merging two party records that a conflict check flagged.

The second person must be a second person

If the second approver always approves without looking, the control is theatre and everyone involved knows it. Fewer dual-authorisation points that are taken seriously beat many that are rubber-stamped.

Two practical rules make it real: the approver should be someone who could plausibly say no, and the request should carry enough context to make refusing possible. An approval request that says only "approve access?" cannot be assessed.

Worked example — a legal practice

A matter involving a partner's family member is classified Highly Restricted. The three fee earners with clearance can open it normally. Anyone else must break glass, stating why, and the practice manager reads those events weekly. Lowering the classification requires dual authorisation from the supervising partner and the COLP, so the case cannot quietly become ordinary.

Recommendations

• Tell staff break-glass exists and is reviewed. A control nobody knows about deters nothing and gets bypassed by phone.
• Set a review cadence and keep it. Weekly is realistic for most; monthly is the most that is still meaningful.
• Investigate the pattern, not the individual, first. Most break-glass is legitimate work meeting an over-tight control.
• Never use dual authorisation as a substitute for training. It slows an action down; it does not make the person better at judging it.