Casework where the file has to hold up
Some casework gets judged twice: once on the outcome, and again on the record of how you reached it — by an Ombudsman, an inspector, a regulator, a court, or your own information governance team. This page is about the second kind. Councils and legal teams both run it, they use different words for it, and they need the same controls underneath: who could see this, when was the clock running, what was sent and when, what was disclosed, and what happens to the file when it is over.
Prove who saw the case, and that the deadline was met.
You are probably here because
- You cannot answer "who has had access to this case" without asking around.
- Statutory deadlines live on a spreadsheet that gets updated after the event rather than before it.
- A clock that should have stopped while you waited for clarification kept running, so the performance figures are wrong in your favour and you know it.
- Correspondence is spread across three mailboxes, and the case file is whichever one somebody opened last.
- You can prove an e-mail left the system. You cannot prove a notice reached the person it was addressed to.
- A bundle has to be renumbered because one document arrived late, after everyone had already cited the page numbers.
- Conflict checking is somebody typing a surname into the contacts list and hoping.
- A redaction is a black rectangle drawn in a PDF editor, and nobody has checked whether the text is still underneath it.
- Records that should have been destroyed years ago are still there — and one that should have been preserved was not.
- The committee papers went out with an appendix attached that was supposed to be exempt.
What is actually going wrong
Ordinary case management assumes the record exists for the people doing the work. Statutory and legal casework assumes something harder: that the record also has to satisfy somebody who was not there, was not involved, and has no reason to take your word for anything. That is a different specification, and it is not met by adding fields.
What tends to happen instead is that each control gets approximated by the nearest thing the software already had. A status field called Closed, which does not stop anybody typing into the record. A spreadsheet of deadlines, which does not escalate. A black rectangle over a name, which does not remove the name. A sent-items folder, which evidences that a message left the building and not that it arrived. Each of those looks like a control right up to the moment somebody tests it, which is invariably the moment it matters.
The other route is to buy a product per regime — one for complaints, one for FOI, one for licensing, one for matters. Each fits its own regime well. None of them fits the other six kinds of casework the same organisation is running, so those carry on in mailboxes and spreadsheets, and the organisation ends up with several partial systems and no single answer to a question that spans them.
What we build
One case record, with the controls that make it defensible built into the platform underneath it rather than modelled as fields on top of it. Access is decided per record, not per table. A deadline is a clock the system owns, with its own holds and its own escalation, not a date somebody types in. Closing a case genuinely freezes it. Disposal is a scheduled instruction that a legal hold can block.
Around that sits the traffic. Inbound e-mail and uploaded messages are captured against the case and threaded reliably; outbound service is recorded as service, against a named recipient and a named document, with a deemed date. Filing and returns go out through an outbox that knows the difference between "we sent it" and "they confirmed receipt". Documents assemble into a paginated bundle with an index, and redactions are recorded as decisions before they are burned in.
It is the same platform every other ActiveManage application is built on, so the casework layer sits alongside the ordinary things a service also needs — forms, portals, reports, dashboards, an API — instead of being a separate island that has to be integrated with them later.
How it goes together
- 01
Model the case in your own language
A council complaint, a licensing application, an FOI request, a safeguarding referral and a litigation matter are the same object with different vocabularies. Cases, parties, organisations, documents, notes and decisions become linked datastores using your words — matter, case, request, referral — because staff adoption is largely a question of whether the software speaks the language of the work.
Built fromDatastores40+ field typesRelated recordsRecord timeline - 02
Decide who is on the case, one record at a time
Per-record access grants read, write or full to named people, security groups or teams. It runs in two modes: open unless granted, which hides nothing until you restrict something, and closed, where an ungranted record is invisible rather than merely unopenable — because being able to see that a case exists has already told you something. Above that sit classification levels and clearances, so a marked record refuses on its marking rather than admitting what it is.
Built fromPer-record accessTeamsClassification & clearanceField permissions - 03
Put the statutory clock in the system, not the spreadsheet
An obligation is elapsed working time between two events on one record, over a business calendar — which covers an SLA target, a statutory deadline, an undertaking, a court direction and a project milestone with one definition of overdue. It warns, it breaches, and it escalates through steps you configure. A hold stops the clock with a mandatory reason and moves the due date, so every list, reminder and screen shows a number that is already correct.
Built fromObligationsBusiness calendarsEscalation stepsSchedule templates - 04
Route the work and cover the absences
Teams with allocation — round-robin, spare capacity, required skills, or manual where the team's own queue is the point. Allocation writes to your datastore's own owner field, whatever you called it, rather than the platform inventing one. Delegation covers annual leave by showing somebody else's work in your in-tray for a period and then expiring, instead of bulk-reassigning four hundred records and destroying the record of who was actually responsible.
Built fromAllocationDelegationIn-trayAssignment pane - 05
Capture what came in and evidence what went out
Inbound e-mail is fetched and filed against the case, and .eml and .msg files can be dropped onto it, all normalised to one shape. Replies thread on an opaque token carried in the headers rather than on the subject line, because a subject line eventually gets edited and a mis-threaded reply files one person's correspondence on another person's case. Outbound service records that a particular document reached a particular recipient by a particular method, with the deemed date that method implies.
Built fromCorrespondenceInbox processingEvidenced serviceDocument management - 06
File outwards, and dispose properly at the end
Court filing, statutory returns, regulator portals and funding claims all go through one outbox with thin per-destination adapters, an idempotency key so an ambiguous timeout cannot file the same claim twice, and separate sent and acknowledged states. At the other end of the life of the file, retention schedules run disposal — behind three independent switches, blocked by legal hold, and never cascading across links.
Built fromSubmissions outboxCompilationsRetention & disposalLegal hold
The platform features doing the work
Nothing here is written specially for this use case — it is the same platform every ActiveManage application is built from. The full feature list is on the platform page.
| Feature | What it does | Why it matters here |
|---|---|---|
| Per-record access control | Read, write or full granted to named users, security groups or teams on an individual record, in either open-unless-granted or fully closed mode. Enforced in the list query and on the single-record read, so the API, the mobile app, search and scheduled tasks are covered too — not only the screens. | "Who is on this case" is the question table-level and field-level permissions cannot answer, and the one an information governance review always asks. A grant narrows and never widens: no access to the datastore still means no access to the record. |
| Classification, clearance and break-glass | Ordered sensitivity levels with caveats and a policy each, matched against a clearance the user holds. Break-glass is an act rather than a permission — a reason is mandatory, it is written down before it takes effect, it expires on its own, and the evidence cannot be deleted. | Every closed user group grows an override — the out-of-hours duty officer, the safeguarding escalation, the coroner's request. The only real question is whether the override is recorded. The scheme itself is configuration, so Government Security Classifications, Caldicott tiers, privilege markings or a committee's Part A / Part B split are all expressible. |
| Record lifecycle and dual authorisation | Open, closed and reopened as a platform state that makes the record genuinely read-only, separate from any status field you also keep. Dual authorisation requires a second, different person to approve a configured action before it takes effect. | No pick-list can stop somebody writing to a closed case. And for the actions where being wrong is expensive — a disposal, a classification downgrade, opening a restricted matter — the rule that the approver may not be the requester is enforced by the platform, not by a form. |
| Obligations, holds and escalation | Statutory and contractual clocks measured in working time over a business calendar, with warnings, breaches, configurable escalation steps, reasoned holds that move the due date, stage history, and attainment reporting that keeps the original deadline alongside the adjusted one. | An FOI clock that stops for clarification, a pre-action protocol that pauses on agreement and a care case that stops for an expert report are the same feature. Attainment reporting can then say "we agreed twenty working days, took twenty-nine, of which nine were held" — which is the honest answer, and the defensible one. |
| Teams, allocation and delegation | Team membership with round-robin, capacity, skills-based or manual allocation writing to your own owner field, an in-tray that includes delegated work, and time-boxed delegation that expires by itself. | Casework fails at handovers and absences. Delegation that leaves the records saying who was actually responsible, rather than bulk-rewriting them and bulk-rewriting them back, is the difference between cover and a corrupted history. |
| Correspondence and evidenced service | Inbound capture from mailbox polling, Microsoft Graph and uploaded .eml or .msg files, threaded by token; inbox actions that append to a thread, open a new case with field mapping, or route to a team queue; and service events recording that a named document reached a named recipient by a named method, with a deemed date. | An e-mail log proves a message left the system, which is not the claim anybody is ever asked to prove. Service is the claim, and it needs the document, the recipient, the method and the date in one place. |
| Submissions outbox | One queue with per-destination adapters for court filing, statutory returns, regulator portals, insurer notifications and funding claims. A unique idempotency key derived from destination, record and payload; separate sent and acknowledged states; a failed destination never blocks the others. | Filing the same claim twice is not a duplicate log entry, it is two claims and somebody has to withdraw one. And "we transmitted it" is a weaker statement than "they confirmed they hold it" — only the second answers the question of whether a return was filed. |
| Compilations and redaction | Ordered sections of documents built into one paginated PDF with an index, bookmarks and page stamping. Late additions paginate behind the page they follow — 5i, 5ii, 5iii — so no existing page number moves. Redactions are recorded as decisions (which area, which page, which reason, by whom) separately from the burn-in, and each method records honestly whether it actually removed content. | A bundle that has been served and cited cannot be renumbered because something arrived late. And a black rectangle drawn over text is not a redaction — the text is still in the file. Keeping the decision apart from the mechanism means the redaction schedule is a report rather than a piece of new work. |
| Duplicate detection, party matching and conflict checking | Scoring policies over the fields you choose, with a weighted mean, veto fields and a review-or-block threshold, run either at the moment of creation or as a scheduled sweep. The same engine scores values that are not yet a record, so a conflict answer arrives before the matter is opened. Merge takes a full snapshot of both records first, so unmerge is possible. | "Is this person already on the system" and "does this person conflict" are one question with different consequences. Two engines would eventually disagree about whether A. Smith is Alexandra Smith, and the one used for conflicts is the one that must not be wrong. |
| Assessment instruments | Versioned scored question sets — risk assessment, file review, supervision, safeguarding triage — where a response is bound to the version it was completed against, published versions are immutable, and both the score and the band are stored at completion. | Guidance changes and thresholds move. An assessment that silently re-scores itself against this year's rules is worse than none, because somebody relied on the original number and it is no longer there to defend. |
| Retention, legal hold and disposal | Retention schedules with review, disposal that genuinely destroys rather than soft-deletes, legal holds that block it, disposal certificates, and tombstones so a linked record never silently vanishes from the case that referenced it. | Keeping everything for ever is a breach in one direction and destroying something under hold is a breach in the other. Disposal sits behind three independent switches, all of which ship off, because it is the only part of the platform that permanently destroys data. |
| Tamper-evident audit and read logging | Every change hashed as it is written, then sealed into a linked chain by a separate pass, so an edited row, a removed row or a rewritten range all stop verifying. Read auditing logs who looked at what, coalesced so browsing a list writes one row rather than two hundred, and a classification level can force it on. | This is tamper-evident, not tamper-proof, and the distinction is worth stating plainly: it does not stop a determined database administrator, it makes a quiet edit a loud one. That is what an auditor actually asks for. Read logging is what answers "who opened this case", as opposed to who changed it. |
| Meetings, agendas and publication | Bodies, meetings and agendas where exposure is three-valued — fully public, title and cited exemption only, or withheld — with clear-days publication, agenda packs, attendance, quorum, a decisions register, minutes and webcast time-marks against agenda items. | In most regimes the existence of a closed item is public even when its report is not, so a system that hides the whole item breaches the same rules it was built to satisfy. One function decides what is public, and both the public agenda and the public pack are built from it, because a second filter written next to the first is how the two eventually disagree. |
What you end up with
- A defensible answer to "who could see this case, and who actually opened it"
- Break-glass access that is reasoned, time-limited, logged and reviewable
- Statutory clocks that escalate before the breach, with holds that are reasoned and reportable
- Attainment figures that state the original deadline as well as the adjusted one
- Closed cases that are genuinely read-only until somebody reopens them
- Correspondence threaded onto the case, and service evidenced against document, recipient and method
- Court filing and statutory returns with separate sent and acknowledged states, and no double filing
- Bundles that survive a late addition without renumbering, and redactions recorded as decisions
- Conflict checks answered before the matter opens, and merges that can be undone
- Retention schedules that dispose properly, and legal holds that stop them
- An audit trail where a quiet edit stops verifying
Whether this is for you
A good fit when
- Local authority teams running statutory work — corporate complaints, FOI and EIR, subject access, safeguarding referrals, licensing, planning enforcement, housing casework — where the clock is set by legislation rather than by policy.
- Law firms and in-house legal teams running matters, where conflict checking, court deadlines, filing, disclosure and legal hold all have to stand up to somebody else's scrutiny.
- Regulators, professional bodies and inspectorates handling complaints and investigations against registrants.
- Housing associations, NHS trusts and social enterprises whose casework carries statutory duties and an Ombudsman on the other side of it.
- Anywhere a single organisation is running several regimes at once and cannot justify buying a separate product for each.
- Organisations that have to demonstrate access control rather than assert it.
Probably not, if
- Casework where nobody outside the team ever audits the record. The general case management page is the better starting point, and it is a smaller build.
- Teams looking for a drop-in product for exactly one regime and nothing else. If one off-the-shelf tool covers your only statutory process, buy it — this pays off where there are several.
- Anywhere the retention and classification policy is still being written. Configuration follows a decided policy; building it early bakes in an answer somebody has not agreed to yet.
- Organisations wanting a full practice management system with time recording, WIP and legal accounts as the primary requirement. Matter management and casework are what this does; billing and ledgers exist on the platform but are not the reason to start here.
How a project like this runs
First
One regime, end to end, with real cases in it — typically the one with the tightest statutory clock, because that is where the controls get tested honestly. The case record, per-record access, the obligation and one intake route.
Then
The remaining regimes onto the same spine, plus the parts that are specific to how you are judged: evidenced service, the outbox destinations you actually file to, bundles, retention schedules and the classification scheme.
Handover
Schedules, classification levels, match policies, assessment instruments and reports are configuration screens, not code. Your own team should be changing them afterwards, because guidance, thresholds and reporting requirements all change without asking us first.
Questions we get asked
What does this look like for a council?
Take corporate complaints. The complaint arrives by e-mail or web form and opens a case; the acknowledgement is recorded as service against the complainant, so there is evidence of what was sent, to whom, and the date it is deemed to have arrived. The statutory response period opens as an obligation on a working-day calendar, and it escalates to the team leader before it breaches rather than after. If you have to stop for clarification the clock is held with a reason, and the reporting afterwards shows both the original deadline and the adjusted one. Allocation routes the case to the right team, and delegation covers leave without anybody re-assigning records by hand. Where the case touches a vulnerable person, classification and clearance keep it to the staff who should see it, break-glass access is logged for information governance to review, and read logging answers who opened the file as well as who changed it. Where the matter reaches a committee, the agenda item can be published title-and-exemption-only so the existence of the item is public while the report is not. When the retention period expires the schedule disposes of the record properly — unless a legal hold is in force, in which case disposal is blocked until it is lifted.
And for a law firm or in-house legal team?
The matter is the case. Conflict checking runs before it opens: the same scoring engine that finds duplicates is given the new party's details and a blocking threshold, so the answer arrives while there is still a decision to make. If the same person is already on the system spelled three ways, merge consolidates them and keeps a full snapshot of both records so it can be undone. Correspondence threads onto the matter — inbound mail, and .eml or .msg files dropped in — so the file is complete rather than distributed across inboxes. Court directions and limitation dates are obligations, and a schedule template can derive a whole chain of dates from one anchor, so moving a hearing moves everything that was not separately agreed. Filing goes out through the submissions outbox, which distinguishes transmitted from acknowledged. Bundles are compiled with an index and page stamping, and a document that arrives late paginates as 5i, 5ii, 5iii rather than renumbering pages other people have already cited. Redactions are recorded as decisions with reasons, so the redaction schedule is a report. Sensitive matters get clearance and, where it is warranted, dual authorisation. Legal hold suspends retention for as long as the matter is live.
How is this different from your general case management page?
Scope and emphasis. The general page is about running a service well — intake, caseloads, outcomes and funder reporting. This one is about casework that gets examined afterwards, so it leads with the controls: record-level access, statutory clocks with holds, evidenced service, disclosure, retention and an audit trail that can be verified. Plenty of organisations need both, and it is one system either way — these are two doors into the same platform, not two products.
Can it handle more than one statutory regime at once?
That is the reason it is built this way. Complaints, FOI, subject access, safeguarding and licensing each have their own clocks, their own routing and their own retention, but they are the same underlying object with different configuration. One system means an officer has one in-tray rather than five, and it means questions that span regimes — everything relating to this address, this person, this property — can actually be answered.
Is the audit trail good enough for an inspection?
Be precise about what it claims. Every change is hashed as it is written and later sealed into a linked chain, so an altered row, a deleted row or a rewritten range all stop verifying. That is tamper-evident, not tamper-proof: it does not prevent someone with database access from making a change, it makes the change detectable rather than silent. Alongside it, read auditing records who viewed a record, which is usually the half people find missing when they look.
What actually stops a record being deleted when it should not be?
Disposal is the only thing in the platform that permanently destroys data, so it sits behind three independent switches that all ship turned off: the schedule itself, the task running out of preview mode, and an arming flag in server configuration. On top of that a legal hold blocks disposal outright. Disposal never cascades across record links either — a closed case being disposed of leaves a tombstone on the open case that referenced it, so the relationship is accounted for rather than quietly disappearing.
We are told our redactions are fine because we draw boxes in a PDF editor. Are they?
Usually not. A rectangle drawn over text leaves the text in the file, where it can be selected, copied or extracted — which is how most published redaction failures have happened. The platform separates the decision from the mechanism: the decision records the area, the page, the reason and the person, and each burn-in method records honestly whether it removed content or only covered it. Where the source is an Office document or an e-mail, the text is deleted before conversion, which removes it by construction.
Do you have a ready-made pack for councils or for legal?
There is a core casework configuration that installs the case spine, and the vertical packs for legal, council, police and healthcare are content we author in customer-demand order rather than something already sitting on a shelf. In practice the first build is the configuration, done with you against a real regime — which is the part that has to match your policies anyway.
Can we still run the ordinary things — forms, a portal, reports?
Yes, and that is a large part of the argument for building it here. The casework layer is part of the same platform as the forms, the customer or resident portal, the report builder, the workflow engine and the API, so a resident submitting a form, an officer working the case and a partner organisation pulling data are all one system rather than three that need integrating.
Is it hosted in the UK?
Yes, by default. The platform is UK-built and UK-hosted and is already used by NHS trusts and public-sector organisations, so UK data residency and the assurance paperwork that comes with it are routine rather than exceptional.
Sound like your week?
Tell us what you are trying to fix and we will tell you whether this is the right shape for it — including when it is not.