A Matter Management System for a Disputes Team

The matter record distinguished external facts from internal planning. A hearing date captured from an order retained its source reference and the person who verified it. A filing deadline derived from that date recorded the applicable rule, calculation basis and any adjustment, rather than appearing as an unexplained calendar entry. Internal target dates were labelled as such. Changes created a new version and prompted review of dependent dates; they did not overwrite the earlier basis. This mattered when a procedural event moved, because the team could see which tasks and reminders had been calculated from the superseded date and decide whether each remained valid.

Tasks used controlled categories, ownership and status but allowed matter-specific detail. A state transition could require a reason or review without pretending to decide legal strategy. Dependencies identified work blocked by a client instruction or external event, while exception views exposed overdue review, an unverified source or a deadline without ownership. The model avoided a universal linear case flow. Instead it provided reusable procedural components that could be applied where relevant and omitted where not. This kept reporting consistent enough for portfolio management while leaving practitioners able to represent unusual directions without hiding them in a generic notes field.

Authorisation was based on matter membership and explicit restricted roles, not merely on broad organisational departments. The API evaluated access for every matter-backed object and used the same policy when producing lists, exports and notification payloads. Search indexes received permission attributes alongside content metadata; inaccessible matters were excluded during retrieval rather than removed from results after matching. Aggregate dashboards were designed against the same boundary because a matter name, counterparty or workload category can itself be confidential. Support access followed a time-bound, approved route and generated an audit event. Database access was not treated as an acceptable operational workaround.

The document repository remained authoritative for files and versions. The platform stored stable external identifiers, document type, relevant version and matter context, then resolved links through the user’s existing repository permissions. Synchronisation handled rename, supersession and removal without copying restricted content into a less controlled store. Where a workflow relied on a specific filed or signed version, the reference was pinned instead of always opening the latest document. Notification text was deliberately sparse and linked recipients back to the authorised application. These choices ensured that convenience features did not create secondary channels in which restricted facts escaped the matter boundary.

Calendar integration was treated as a projection, not the system of record. The matter platform issued stable event identifiers and maintained the deadline’s provenance, status and dependencies. Updates to an external calendar could not silently alter the controlled date. Reminders were generated from policy and user preference but carried the current matter access check at delivery time, preventing a person removed from a matter from continuing to receive details. Delivery failure remained visible to the deadline owner and operational support. A reminder was evidence of an attempted notification, not evidence that the underlying obligation had been discharged.

Deadline calculations were implemented as explicit, versioned rules with test cases drawn from the team’s accepted interpretations. The application displayed the inputs and resulting date so a practitioner could assess them, and uncertain or exceptional situations required manual confirmation. Changes to a calculation rule affected future derivations unless an authorised review deliberately recalculated existing dates. Tests covered non-working days, timezone boundaries, amended source events and dependencies already marked complete. This design resisted false precision: the system supported consistent calculation and escalation while preserving the distinction between a software result and an approved legal deadline.

The former portfolio spreadsheet mixed status reporting with data repair. In the new application, views were assembled from matter facts, tasks, dates and ownership, then linked directly to records needing attention. Definitions such as active, stayed, awaiting instruction and closing were agreed and encoded, with exceptional states visible rather than squeezed into the nearest category. Review packs showed freshness and source status so an old update could not present as current simply because it remained in a cell. Matters absent from a user’s permission scope were excluded at query time, including from totals and export files.

Migration focused on active operational value. Tracker rows were staged with source location and original values, then matched to matters and users through reviewable rules. Free-text status did not become an invented structured state; ambiguous rows entered an owner queue. Document links were tested against repository identifiers, and upcoming dates were reverified against their cited source. After release, old trackers became read-only before removal, allowing teams to identify missing decisions without continuing parallel updates indefinitely. Retention, closure and legal-hold behaviour were then exercised end to end, including removal from routine views while preserved material and its audit history remained discoverable to authorised roles.