Record Access Roles

Row-Level Access

Datastore permissions answer "may this person work with cases at all". Record access answers "may they see this case". They are different questions and they need different mechanisms.

Where to find it

Architect Panel → Security:

• Record Access Roles — the roles defined per datastore, and their default level
• Permissions — datastore-level grants, which come first

Architect Panel → Data:

• Datastores — the Permissions row action, for datastore-level access

Why datastore permissions are not enough

Grant a social worker access to the case datastore and, without row-level control, they can see every case in the organisation. That is rarely what anybody intends, and in regulated work it is a reportable problem rather than an inconvenience.

The instinct is to solve it by splitting one datastore into several — cases per team, per region, per service. Resist it. You end up with the same fields defined many times, reporting that has to union everything back together, and a record that cannot move between teams without being recreated.

Roles are defined per datastore

A record access role is a named kind of relationship somebody can have with a record in a particular datastore — owner, assignee, reviewer, observer — each carrying a default access level and an order.

Defining roles first means grants become meaningful rather than numeric. "Priya is a reviewer on this case" is something a person can read and judge; "Priya has level 2" is not.

Grants attach a principal to a record

A grant records who has access to which record. The principal can be:

• An individual, identified by the same three-part identity used throughout the platform.
• A security group.
• A team.

Granting to a group or team is almost always better than granting to individuals. People join and leave; a record granted to fifteen named individuals becomes a maintenance problem the moment somebody moves on, and nobody goes back to tidy it.

Both layers must permit it

Row-level access does not override datastore permissions — it narrows within them. Somebody with no permission on the case datastore is not granted access by a record-level grant, and this is the usual explanation when a grant appears to do nothing.

Check the datastore layer first when a grant is not working. It is the more common fault by a distance.

Design the roles before granting anything

Three or four roles usually cover a datastore. Write down what each is allowed to do before creating them, because roles get used as soon as they exist and changing what one means afterwards silently changes existing grants.

Worked example

A council's case datastore defines owner, co-worker, reviewer and observer. A complex case is owned by one social worker, with the safeguarding team granted as reviewer. When the case is escalated, the escalation team is added as co-worker rather than the case being copied — so it stays one record with one history.

Recommendations

• One datastore with row-level access, not one datastore per team.
• Define roles before you start granting.
• Grant to groups and teams, not to individuals, wherever you can.
• Check the datastore layer first when a grant seems ineffective.

Reasons, Expiry and Revocation

A grant is not just a permission — it is a decision somebody took, and it is recorded as one.

Where to find it

Architect Panel → Security:

• Record Access Roles — the roles grants are made against

Architect Panel → Activity:

• Activity Log — where the grant itself is audited
• Record Read Log — what the granted person then read

What a grant records

• The record and the principal.
• The access level and role label.
• A reason.
• Granted by and granted at.
• An optional expiry.
• A revoked at timestamp.

Always fill in the reason

It is the field that makes an access review possible. A list of grants with no reasons can only be reviewed by asking each grantor what they were thinking, which in practice means the review does not happen and the grants stay forever.

"Covering annual leave for the case owner" or "joint working with adult services" takes seconds to write and makes the decision reviewable a year later by somebody who was not there.

Use expiry as the default

Most access is genuinely temporary — covering leave, a period of joint working, an investigation, an audit. Setting an expiry when you make the grant is the only reliable way to have it removed, because nobody comes back later to take access away.

Access that accumulates and never lapses is how an organisation ends up unable to answer who can see a record. An expiry costs nothing to set and can always be extended.

Revoked, not deleted

Withdrawing access stamps a revocation time rather than removing the row. The grant remains visible as something that existed and ended.

This matters when answering who could see a record during a particular period — a question that arises after a complaint or a leak. A deleted grant makes that question unanswerable, and its absence looks worse than the grant would have.

Reviewing grants

Look periodically for grants with no expiry, grants older than your policy allows, and grants to individuals who have since changed role. On a sensitive datastore this belongs in a routine rather than being done when somebody asks.

Grant and read are different records

A grant says somebody could see the record. Whether they did is in the read log, where that datastore has read auditing enabled. Both are needed to answer the question people usually mean.

Worked example

A manager grants a colleague access to a case for two weeks to cover leave, with the reason recorded. The grant lapses on its own. Three months later a complaint asks who had access that fortnight — the expired grant is still there with its reason and dates, and the read log shows which records were actually opened. Neither answer required anybody's recollection.

Recommendations

• Never leave the reason blank.
• Set an expiry by default and extend if needed.
• Revoke; never delete.
• Review open-ended grants on a schedule.