Document Control

Owners and Deputies

A controlled document needs somebody who answers for it. Not the person who uploaded it and not whoever approved it once — somebody now.

Where to find it

Architect Panel → Data → Document Control is the register. On a record, the Control panel of the Documents pane is where an owner is set.

A creator is not an owner

The distinction the whole section turns on. Whoever uploaded a policy in 2019 has probably changed job. Whoever approved it answered for that version and not for the document. Ownership is a current, named responsibility, and it is the thing reminders are sent to.

A deputy, because people go on leave

The deputy is told alongside the owner rather than instead of them. A review that falls due during somebody’s fortnight in Spain should not wait for them, and should not silently become somebody else’s.

A team can own it

Where the honest answer is a role rather than a person. “The information governance team owns this” survives people joining and leaving; “Sarah owns this” does not.

The first owner is an administrator’s act

Because a document with nobody answering for it has nobody who could be trusted to name somebody. After that, the owner or the deputy can transfer it — which is what a leaver needs.

The most useful panel is the one about absence

The register’s Nobody owns these list. Everything else on that screen shows things somebody has already thought about; that list shows the ones nobody has, which is where a register earns its keep.

A document with a review date and no owner is the exact case it exists for: the clock runs and the reminder has nowhere to go.

Transfers are recorded

When, and by whom. “Who was responsible for this in March” is a question that gets asked, and a column that only holds the current answer cannot answer it.

Worked example

A compliance manager opens the register and finds eleven unowned documents, nine of which are superseded and two of which are live policies with review dates. The two get owners that afternoon; the nine get withdrawn. Nothing was broken — it was simply invisible.

Recommendations

• Set the owner when you set the review cycle, not afterwards.
• Always name a deputy for anything with a deadline.
• Own by team where the responsibility is really a role.
• Work the unowned list monthly. It only grows.

Review Cycles and Expiry

Two different clocks that are easy to confuse. Review means look at this again. Expiry means this stops being valid.

Where to find it

On a record, the Control panel sets both. Architect Panel → Data → Document Control shows what is overdue, what falls due soon, and what expires soon.

Why they are separate

A policy reviewed every two years does not become invalid on the day it is due — it becomes overdue, and somebody should look at it. A DBS check, an insurance certificate or a licence genuinely stops being worth anything on its date.

Treating expiry as a review means a document nobody has looked at is still presented as current. Treating review as expiry means everything falls off a cliff and people stop trusting the dates.

Recording a review resets the clock

Recording one meets the obligation the sweep opened and sets the next date from the cycle. That is the loop: a date, a reminder, an act, a new date.

A review recorded against a document with no cycle simply records that somebody looked.

Expiry has a warning window and a choice

The warning window decides how far ahead the reminders start — thirty days before is the default shape. On the day itself, the document either:

• notifies — somebody is told and the document stays as it is, or
• withdraws — the document is withdrawn automatically.

Choose withdrawal only where continuing to present the document is worse than losing access to it. It cannot be undone.

The clocks only run if the tasks do

Two scheduled tasks are involved and both ship switched off: one opens the clocks and the other fires the reminders. With only the first enabled, dates are tracked and nobody is told — which looks exactly like the feature not working.

The preview of the first task says so explicitly when the second is disabled.

Expiring is not the same as expired

The register separates them, because the useful list is the one you can still act on. A certificate expiring in three weeks can be renewed; one that expired last month is an incident.

Worked example

An organisation sets a twelve-month review on its policies and a real expiry on its ninety insurance certificates, with thirty days’ warning and notify rather than withdraw. The brokers get chased a month out, the register shows what is coming, and nothing disappears from a case at midnight.

Recommendations

• Use expiry only for things that genuinely stop being valid.
• Prefer notify to withdraw unless presenting the document is the risk.
• Enable both tasks, and read both previews first.
• Set the warning window to the renewal lead time, not to a round number.

Approval and What Is In Force

Which version of a document people must actually follow — answered from approvals and effective dates, never read off a status column.

Where to find it

On a record, the Control panel submits, approves, records reviews and withdraws. Architect Panel → Data → Document Control is the register of what is in force across the organisation.

It is derived, not stored

The design decision worth knowing. A document marked “final” with no approved control row satisfies nothing, and the register reads the approvals rather than the state column.

That is deliberate: it means somebody adding another way to set “final” cannot accidentally make a document count as approved.

In force is a date question

A version approved today to take effect next month is approved and not in force. A draft v4 can exist while approved v3 is what people must follow.

So the count of approved versions is not the count of documents in force, and the register keeps the two lists apart.

Approval is per version

Not per document. A new version starts again, which is the entire point — the thing being approved is a specific text, and a fresh version is a different text.

Who may do what

• Read — anybody who can read the document.
• Submit, approve, review, withdraw — an administrator, or the document’s owner or deputy.
• Name the first owner — an administrator only.

Waiting on an approver is a list

The register shows what has been submitted and not yet acted on, and who it is with. A submission nobody is told about sits there indefinitely, which is why that panel exists rather than a status somewhere.

Withdrawing needs a reason

And the reason is kept. “Why is this policy no longer in force” is asked long after everybody involved has forgotten.

Worked example

A safeguarding policy is revised. v5 is submitted in February, approved in March with an effective date of 1 April. Through March the register shows v4 in force and v5 approved-not-yet-in-force — and staff being asked to acknowledge v4, correctly, until the first of the month.

Recommendations

• Use effective dates rather than approving on the day you want the change to bite.
• Read the register, not the state column.
• Work the waiting-on-an-approver list; it is where documents go to stall.
• Write the withdrawal reason as though somebody will read it in three years.

Read and Acknowledge

Ask people to confirm they have read something, and be able to say who has not.

Where to find it

On a record, the Documents pane shows a banner while an acknowledgement is outstanding for you. Architect Panel → Data → Document Control has the Awaiting acknowledgement panel.

An acknowledgement is of a version

Not of a document, and this is the whole point. A new approved version starts everybody again.

“I have read the fire policy” is worth very little next to “I have read version 4, the one that changed the evacuation route”.

The audience is a team, and outstanding is worked out

You name security groups rather than people. Who still owes an acknowledgement is computed when asked: the members of those groups, minus the people who have confirmed.

So somebody who joins the team tomorrow owes it tomorrow, and nobody has to reissue anything to anybody.

Nobody asked looks exactly like everybody done

If you only count what is left. So the summary reports the size of the audience separately from the number outstanding, and an audience of zero is called out rather than shown as a clean sheet.

“0 of 0 confirmed” means nobody was ever asked.

Acknowledging is not controlling

It is gated on being able to read the document, not on owning it. Confirming that you have read something is what the audience does, and requiring control permission to do it would mean nobody could.

Chasing goes to the worklist

Outstanding acknowledgements are chased into the tray people already work from rather than only by e-mail, because an acknowledgement is something to do. An e-mail asking somebody to go and find a document is easier to ignore than a task.

It is a record, not a control

Nothing stops somebody clicking without reading. What the system can honestly say is that a named person confirmed a specific version on a specific date, which is what an auditor asks for and all any system of this kind provides.

Worked example

A revised lone-working policy is approved with the whole operations group as its audience. Two weeks later the register shows 74 of 91 confirmed. The seventeen are chased in their worklists, and three of them turn out to have left — which is a leavers-process finding rather than a documents one.

Recommendations

• Set the audience when you submit, not after approval.
• Use groups that are maintained. The list is only as good as the membership.
• Watch for an audience of zero.
• Expect a new version to reset it — that is the feature working.

Document Reminders

A date nobody is told about is not a deadline. Reviews, expiries and acknowledgements chase the people responsible.

Where to find it

Architect Panel → Automation & Tasks → Tasks:

• Document Review and Expiry — opens the clocks and expires what is due
• Obligations — fires the reminders and their escalations

Both tasks, or nothing happens

The single most common way this is switched on wrongly. One task opens a clock when a review falls due; the other is what actually escalates and sends. With only the first enabled, everything is tracked and nobody is told.

The first task’s preview says so in as many words when the second is disabled. Read it before arming anything.

Both channels, because either alone fails recognisably

A reminder raises a task in the owner’s worklist and sends an e-mail.

E-mail alone is filtered, missed, and invisible to anybody covering for somebody on leave. A worklist item alone is only seen by somebody who logs in and looks. Together they fail rarely, and they fail visibly.

Escalation steps, including one before the date

Steps are configured against the obligation type, in days relative to the due date — and a step may be negative, meaning before it. Expiry ships with a step thirty days ahead, because a certificate you are told about on the day it expires is a certificate that has expired.

Nobody to tell is reported, not swallowed

A document with a review date and no owner reaches its escalation with nowhere to send it. That is written to the log rather than quietly recorded as escalated — and it is exactly what the register’s Nobody owns these panel is for.

Recording the review closes the loop

The clock the sweep opened is met, and the next one opens from the cycle. Escalations stop because the thing was done, not because somebody dismissed them.

Test it before you trust it

Set a review date in the past on one document you own, run both tasks in preview, and read what they say they would do. Then enable them and confirm you get both the task and the e-mail.

Worked example

A policy’s twelve-month review falls due. The owner gets a worklist task and an e-mail; nothing happens for a fortnight; the escalation reaches the deputy. The review is recorded, the obligation closes, and the next date is set automatically twelve months out.

Recommendations

• Enable both tasks or neither.
• Preview first, on a real overdue document.
• Keep a step before the expiry date, not only on it.
• Fix unowned documents before turning reminders on, or the first run is mostly errors.

Documents and Disposal

When a record is disposed of under a retention schedule, its documents go with it — with two deliberate exceptions.

Where to find it

Architect Panel → Data. Retention schedules and legal holds are documented under Case Management → Retention & Legal Hold; this is what that disposal does to documents.

What goes

The link between the document and the disposed record always goes. Where that was the document’s last link, the document itself goes too: its versions, its files, and its sidecars — control, ownership, acknowledgements, access log, library column values, watches and extracted text.

What survives, and why

A document attached to three cases, one of which is disposed of, keeps the other two. It is the same file, and the other cases have not reached the end of their own retention.

That is the union rule working in the other direction, and it is the reason disposal removes a link rather than a document.

A file store document is not destroyed

The second exception, and the one to disagree with if you are going to disagree with any of this. A document adopted from a file store points at bytes that belong to a separate library with its own lifecycle, which other people are still browsing.

Disposal removes the document — its ledger rows, versions and sidecars — and leaves the file in the store. Deleting a file out from under a library that never agreed to this retention schedule, on the strength of one adoption, would be worse.

The certificate gets a count

A destruction certificate records how many document rows were removed rather than naming each one. Each destroyed document is written to the system log with its title, filename and size before it goes, so the detail exists — it is simply not in the certificate.

A missing file is not a failure

On an estate of any age, plenty of file rows point at objects that are no longer in storage. Disposal removes the record either way rather than refusing, because a disposal that will not complete because the thing was already gone is not a useful disposal.

Worked example

A closed case reaches the end of its schedule. Four of its five documents are on no other case and are destroyed with it; the fifth is a shared site survey on two live cases and only its link goes. The certificate records five dependants removed, and the survey is still there where the other cases expect it.

Recommendations

• Check what else a document is on before assuming disposal will destroy it.
• Do not rely on disposal to clear a file store — it deliberately will not.
• Keep the system log if you need per-document evidence of destruction.