Reading, Watching & Auditing

Who Read What, and When

Every read of a document is recorded — and so is every refusal, which is often the more interesting event.

Where to find it

Architect Panel → Security → Document Access for the report across the whole library. On a record, the Access panel of the Documents pane shows one document’s history to administrators.

What is recorded

The document and version, who (or what — a person, a link, an emailed key), when, from which address, and the outcome. A refusal keeps the reason.

Documents, not files

A deliberate line. An upload that belongs to no document writes nothing, so the thousands of avatars, logos and inline images the platform serves are not logged.

A file access log is a different feature with a different volume and a different privacy footprint, and it should be decided on its own merits rather than arrived at by accident.

Refusals are the point

Somebody reaching repeatedly for a document they may not have is exactly what a log is for, and one that recorded only successes could not show it.

“Access granted” is not “opened”

The honest limit, and it is stated in the interface as well as here. Where files are held in S3, the platform authorises the read and hands the browser a short-lived URL; the bytes then move browser-to-bucket without passing through the platform again.

So the row means access was granted. The read follows within a few minutes in practice, and the URL is deliberately short-lived for exactly that reason — but the log does not claim to have watched it happen.

Nobody can clear it

There is deliberately no button anywhere that wipes the log. A record somebody can erase on a bad afternoon answers no question anybody would trust it to answer.

What there is, is a configurable keep window that the housekeeping task prunes to. It defaults to keeping everything, because losing the record of who read what is not a thing to do by accident.

Worked example

A complaint alleges a report was shared inappropriately. The access log shows four reads: three caseworkers on the case and one refusal from somebody who was not. The refusal is the answer — nothing leaked — and it took one screen.

Recommendations

• Leave the keep window at everything unless you have a reason and a policy.
• Look at refusals, not only reads.
• Say "granted" rather than "viewed" when you quote it to anybody.
• Pair it with the Sharing panel: one says who did, the other says who could.

Alerts When a Document Changes

Ask to be told when a document changes. “The site licence has a new version” is a fact half a dozen people need and none of them own.

Where to find it

On a record, the Documents pane → Watch. Choose whether you want to hear about new versions, changes of state, or both.

E-mail, not a worklist task

A reminder is something to do and belongs in a tray that can be cleared. An alert is something to know. Filling somebody’s worklist with items they cannot complete would make the worklist useless, which is the more valuable of the two.

You are told only what you could have seen anyway

The important behaviour. Your access is checked when the alert is about to be sent, not when you subscribed.

Somebody who subscribed while they worked a case and has since been taken off it stops being told — and is not told that they have stopped, because “v4 of the Riverside settlement has been added” is itself a disclosure about a document they may no longer see.

Access coming back tells you what you missed

The subscription is not removed and its position is not advanced while you cannot read the document. Return from a secondment and you are told what changed while you were away, which is what anybody would expect.

Changes collapse

Three versions added between two runs of the housekeeping task produce one e-mail saying the document is now at v5, not three e-mails. For an alert that is the better trade.

It arrives when the task runs

Alerts are sent by the documents housekeeping task rather than the instant something changes, so they arrive on that schedule. The task ships switched off like every other.

A count, never a list

The panel tells you how many people are watching, not who. Who is interested in a document is a different and more sensitive question, and it is answered on the Sharing panel for administrators.

Worked example

Four managers watch the organisation’s lone-working policy. It is revised and approved; all four are e-mailed once. One of them moved department last month and no longer has a route to the policy — they are not e-mailed, and their subscription waits quietly in case they come back.

Recommendations

• Watch state changes on controlled documents and versions on working ones.
• Enable the documents task, or nothing is ever sent.
• Do not use it as a distribution list — acknowledgements do that properly.

Putting Back a Removed Document

Detaching the wrong document is the commonest accident there is with documents. It is also, now, reversible.

Where to find it

On a record, the Documents pane → Recently removed. It lists the last ninety days, with who removed each one and when.

Removing was never deleting

Detaching a document from a record has always kept the link rather than destroying it, because “this document used to be on this case” is itself disclosable — a disclosure schedule that cannot show what was removed and when is incomplete.

What was missing was any way to see that, or to undo it.

It shows what you could still read

The list is trimmed to documents you have access to. Being removed from a record revokes nobody’s interest in a document, and a list of everything ever taken off a case would name documents precisely because they are no longer visible on it.

Putting one back is the same act as attaching

So it carries the same rule: you must be able to read both the record and the document. Seeing something in the list is not enough on its own.

That second check is not redundant, and the case is worth stating. A removed link is exactly the state in which the record no longer grants the document — so somebody who can read the case but reached the document only through that link must be refused, or the check would let them hand it back to themselves.

It re-grants access

Everybody who can read the record can read the document again. Restoring is not a quiet correction; it is the same access decision that attaching was.

Putting it back twice is harmless

If somebody has already re-attached the document by hand, restoring does nothing rather than giving the record the same document twice.

Documents themselves are never soft-deleted

There is no “delete this document”. A document leaves a record by being unlinked, and leaves the system only through retention disposal, which is authorised and certificated. So this is a recycle bin for attachments, and a document nobody can reach is found through the library instead.

Worked example

A caseworker tidying a cluttered case removes four attachments, one of which was the signed agreement. It is back on the record inside a minute, the removal and the restoration are both recorded, and nobody has to find out who has a copy.

Recommendations

• Check here first when a document has “disappeared” from a case.
• Remember it re-grants access — the same care as attaching applies.
• Do not use detach as a filing tool. Roles describe what a document is; removing it says it does not belong.