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.

Access Links

An access link lets somebody with no account reach one specific record for one specific purpose, such as downloading a document or completing a risk assessment. Unlike older link types, an access link can expire, can be limited to a number of uses, and can be taken back. This article explains how they work across the platform, so you can judge when to issue one and how to withdraw it.

Where to find it

Access links are created and withdrawn on the record they open, not from a menu. Today two features issue them:

• Document share links, on a document's sharing panel, under Share links. See Document Access.
• Risk assessment links, which let somebody without an account fill in an assessment. See Assessment Instruments.

Architect Panel → Data:

• Datastores — the Access Links datastore holds every link ever issued, for audit; it deliberately has no menu entry of its own

What makes an access link different

• One record, one purpose. A link is issued for a particular record and states what it is for. A link made to download a document cannot be used to open anything else, even on another part of the site.
• It expires. Document share links last 168 hours (seven days) unless you choose otherwise; assessment links last 30 days.
• It can be limited to a number of uses. Document share links default to five downloads. Assessment links have no use limit, because an assessment may be completed over several sittings.
• It can be taken back at any moment, and stops working immediately.
• It is shown once. The platform stores only a scrambled fingerprint of the link, never the link itself. When you create one, copy it straight away: it cannot be displayed again. If it is lost, create another and take back the first.

Creating and withdrawing a document share link

1. Open the document and its sharing panel. Only an administrator can create share links.
2. Under Share links, fill in Who it is for (a note), Hours it lasts and Times it can be used, then click Create a link.
3. Copy the link from the message "Link created. Copy it now - it cannot be shown again." and send it to the person.
4. To withdraw it, find it in the list (which shows who it was for, how many uses are spent, when it expires and who made it) and click Take back. It is then marked "taken back".

A document that may not be downloaded, or that lives in a File Store, cannot be shared by link; the refusal says why.

What the person holding the link sees

A working link opens the document or assessment with no sign-in. A link that has expired, been used up, been taken back, or was never valid gets the same message, for example "This link is not valid. It may have expired, been used already, or been withdrawn." The platform never says which, so a stranger guessing links learns nothing. Repeated failures from one address are counted and can get that address blocked, as with failed sign-ins.

Who to tell what

The note in Who it is for is a record of who you meant to send the link to. It is not checked: anybody the link is forwarded to can use it. Choose the expiry and number of uses with that in mind, and use a named grant instead when the person has, or can be given, an account.

What goes wrong

• "Only an administrator can create a share link." Share links are administrator-only.
• The recipient says the link does not work. Check the link's row: used up, expired or taken back. Create a fresh one if they should still have access.
• A link was sent to the wrong person. Take it back at once. Its row records whether it had been used, and when.

Worked example

A housing association needs to send a surveyor's report to an external contractor without creating an account. An administrator creates a share link for "Contractor - Smith & Co", lasting 48 hours with 3 uses, and e-mails it. Two days later the list shows "2 of 3" used and the link expired. When the contractor asks again a month later, a new link is issued; the old row stays as a record that the first was sent.

Recommendations

• Prefer a named grant when the recipient can have an account.
• Keep expiry short and uses few for anything sensitive.
• Copy the link immediately; it cannot be shown again.
• Take back links as soon as their purpose is served.